On Wed, 23 Sep 2026 01:12:40 GMT, Sergey Bylokhov <[email protected]> wrote:
>> Jayathirth D V has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Update test
>> - Fix PL
>> - Merge remote-tracking branch 'upstream/master' into 4753654
>> - Merge remote-tracking branch 'upstream/master' into 4753654
>> - Fix conflict in PL
>> - Use EDT for canvas
>> - Initial change
>> - Remove from PL
>
> test/jdk/java/awt/Component/GetScreenLocTest/GetScreenLocTest.java line 75:
>
>> 73:
>> 74: EventQueue.invokeAndWait(() -> {
>> 75: p = canvas.getLocationOnScreen();
>
> This is an AWT component, you do not need to use EDT to access that. I am
> pretty sure one of the reasons for the failure is updating the
> coordinates/other props on one thread, toolkit/main/EDT, and reading it
> without proper synchronization on another one.
>
> Same question about -Dsun.java2d.uiScale=1. if the canvas receives the wrong
> coordinates at some specific dpi that is a bug in the product, or the test
> expectation is wrong. This is one of the primary goals of the test to test
> the coordinates of the component on the screen including different DPI, since
> we have specific code paths which executed only in hidpi mode.
I don't think using EDT for getLocationOnScreen() can cause synchronization
issues in this test. There is no other thread which actually hold tree lock
when we are executing this call. I see no harm because of using EDT here.
With additional logging added in the test, i can see that we are receiving all
the required events properly on all platforms. If we had synchronization issues
with latest test we would see intermittent failures, which is not the case.
Regarding uiScale=1, as explained previously i am seeing issue only in
particular display scaling in Windows. Windows supports absolute fractional
scaling and rounding of values from float to int is causing these difference in
coordinates. Expectation from test that moving coordinates in user space and
using robot to get same pixel in fractional calling is not right. As mentioned
previously i can use margin for where we receive mouse event and not check
exactly at (0,0) without using uiScale 1. We can check for like (3,3) and go
back (-3, -3) with some margin for error. Instead of that i am using uiScale=1
without margin which is more strict.
If in future we see some intermittent failures added logs will show more
details and we can introduce margin for pixels from where we are receiving
mouse events.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32764#discussion_r4131049219
