On Wed, 30 Sep 2026 05:07:22 GMT, Sergey Bylokhov <[email protected]> wrote:
>> 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. > >>I don't think using EDT for getLocationOnScreen() can cause synchronization >>issues in this test. > > There is no harm for sure; my point is the opposite: the usage of EDT here > makes the code more synchronized, and because of that we can miss the real > bug where at least EDT/main/toolkit threads work with a frame in parallel, > and all that should be properly synchronized. EDT should be used only for > Swing, where all/most accesses from all threads are implemented by posting > events. > >> Expectation from test that moving coordinates in user space and using robot >> to get same pixel in fractional calling is not right. > > Why is it not right? It is our code that converts the user-space coordinates > to device space and back. In this case, even if there are some rounding > errors, why could it be that large, from "3" to "-3"? Calling getLocationOnScreen() on EDT or not is not changing the result of this test. I have removed using EDT for getLocationOnScreen(). 3 to -3 movement was just an example that i shared for margin usage, it is not a tested margin limit. As mentioned previously the Windows specific failure was only seen locally on my Windows machine with only 150% display scale. Since we have doubts about whether this rounding of coordinates for absolute fractional scaling is product issue or not, i have created a separate issue [JDK-8393514](https://bugs.openjdk.org/browse/JDK-8393514). I don't see this Windows specific failure in our CI testing also, but to avoid some intermittent future failure i am problem listing this test only on Windows under newly created Windows specific bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32764#discussion_r4182538673
