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

[Sergey Bylokhov]

This method call getGraphicsConfigurationAtPoint() which is located in 
the SwingUtilities2 and the robot class already depends on it:
http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/share/classes/java/awt/Robot.java#l508

On 21/05/2018 10:03, Phil Race wrote:
> 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
>>
> 


-- 
Best regards, Sergey.