+1. Thanks, Jay
> On 29-Apr-2020, at 4:39 AM, Philip Race <philip.r...@oracle.com> wrote: > > +1 from me. > > -phil. > > On 4/26/20, 9:13 PM, Prasanta Sadhukhan wrote: >> >> Sure..test updated... >> >> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.2/ >> <http://cr.openjdk.java.net/%7Epsadhukhan/8232243/webrev.2/>Regards >> Prasanta >> On 25-Apr-20 8:01 PM, Philip Race wrote: >>> >>> 96 SwingUtilities.invokeAndWait(() -> createUI()); >>> 97 >>> 98 Point p = textPane.getLocationOnScreen(); >>> 99 Robot robot = new Robot(); >>> >>> For the sake of stability would it be better to create the robot and wait >>> for idle before getting the pane location ? >>> >>> -phil. >>> >>> On 4/24/20, 9:31 PM, Prasanta Sadhukhan wrote: >>>> >>>> Thanks for your review. All comments incorporated >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.1/ >>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8232243/webrev.1/>Regards >>>> Prasaant >>>> On 25-Apr-20 4:25 AM, Philip Race wrote: >>>>> In the test >>>>> 56 textPane.setFont(new java.awt.Font("Arial", Font.PLAIN, 12)); >>>>> >>>>> you should use a font you know exists. If the idea is that this test is >>>>> just >>>>> for windows, then @requires windows ? >>>>> >>>>> And >>>>> 94 System.setProperty( "sun.java2d.uiScale", "1.5" ); >>>>> >>>>> should be set as a command line property to the test since that is what >>>>> we do >>>>> elsewhere, then you can have the test run several times at different >>>>> scales. >>>>> >>>>> Also currently 1.5 is truncated to 1 except on Windows ... >>>>> >>>>> If you want to test on Linux or Mac you need 2. >>>>> Another reason to use the command line way of doing it. >>>>> >>>>> >>>>> -phil >>>>> >>>>> >>>>> On 4/16/20, 3:16 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for an issue where it is seen that, with a screen >>>>>> resolution higher than 100% and then clicking in a JTextPane, the caret >>>>>> (insertion point) is not aligned with the cursor. >>>>>> >>>>>> The issue seems to stem from the fact that caret position calculation in >>>>>> DefaultCaret class utilises API that uses integer calculation than >>>>>> floating point calculations. >>>>>> >>>>>> This issue is in continuation to the fix done for JDK-8199441 where the >>>>>> issue was fixed for JTextArea. >>>>>> [http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031 >>>>>> <http://hg.openjdk.java.net/jdk/jdk/rev/480c2ae4d031>] >>>>>> >>>>>> The code flow for JTextArea was >>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>WrappedPlainView#viewToModel=>Utilities.getTabbedOffset >>>>>> >>>>>> >>>>>> whereas for JTextPane it it is >>>>>> DefaultCaret#positionCaret=>BasicTextUI#viewToModel=>BoxView.viewToModel=>CompositeView#viewToModel=>GlyphPainter1#viewToModel=>Utilities.getTabbedOffset >>>>>> >>>>>> Now, getTabbedOffset utilises FontMetrics.charsWidth() which uses >>>>>> integer arithmetic to get the caret position. >>>>>> The same getTabbedOffset uses Font.getStringBounds() which uses floating >>>>>> point arithmetic via Rectangle2D.Float. >>>>>> >>>>>> Proposed fix is to make sure proper floating point getTabbedOffset API >>>>>> is used so that floating point calculations is done for char width. >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8232243 >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8232243> >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/ >>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8232243/webrev.0/> >>>>>> >>>>>> Regards >>>>>> Prasanta
