<Swing Dev> RFR JDK-8232243:Wrong caret position in JTextPane on Windows with a screen resolution > 100%

[Philip Race]

+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/
>
> 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/
>>>
>>> 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]
>>>>>
>>>>> 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
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8232243/webrev.0/
>>>>>
>>>>> Regards
>>>>> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20200428/82ec5282/attachment.htm>