<AWT Dev> [11] Review Request: 8196030 and 8190326

[Phil Race]

I don't understand why the new method is added in SwingUtilities2 instead
of directly in WRobotPeer.java since
a) This makes AWT internals depend on Swing internals.
b) There's no other client of this method.

-phil.


On 05/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
>