I can confirm that the patch fixes the problem for me on the Windows 10
machine on which I initially reported the bug. The change in
awt_Robot.cpp looks reasonable to me. I didn't review it thoroughly,
though (and just skimmed the rest).
-- Kevin
On 5/18/2018 12:38 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk11.
Bugs:
8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI
https://bugs.openjdk.java.net/browse/JDK-8196030
8190326: Robot.mouseMove uses scaling factor of main display on
unscaled second display
https://bugs.openjdk.java.net/browse/JDK-8190326
Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04
Description:
This change will fix two issues:
- 8196030: In the Windows 10 relative mouse moving is broken.
Solution is to change the code to use the absolute mouse location.
Actually the fix reverts the changes which were done in JDK-4288230
[1](It is interesting that previously the absolute mouse position was
broken). Take a look to the function which is used to calculate the
mouse position, this is the only way I found to align coordinates
which passed to windows(::SendInput() and coordinate which returned by
windows(::GetCursorPos().
- 8190326: the logic how we convert coordinates from the user space
to device space is changed. Previously we use the transformation of
the main screen, now we will find the appropriate screen(where
coordinates are located) and then use transformation of this screen.
I have tested the fix on win7/10 using scales:100%,125%,%150,%175,%200
in multi-monitor configuration. But the new test is quite strict and
may fail if there are some rounding error in some variations of screen
resolution+scale+screen locations. So I expect some reports for this
test.
Notes:
- The logic in the new method in SwingUtilities2 is similar to
Robot.createCompatibleImage(), but the new method uses
Region.clipRound() instead of floor/ceil. The reason is that we use
same logic in native. I think that Robot.createCompatibleImage()
should use clipRound() as well. Will check this later in separate bug.
- Similar but not the same bug exists in Robot.getPixelColor() which
uses the scale of the main screen, and uses simple cast to (int), but
it affects all platforms. Will check this later in separate bug.
[1] https://bugs.openjdk.java.net/browse/JDK-4288230
