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

[Kevin Rushforth]

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
>