+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
