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

[Sergey Bylokhov]

It is also used by, Window peer on windows:
http://hg.openjdk.java.net/jdk/jdk/file/f4735ff8d17d/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java#l662

I guess that unix peers should use it as well in the same way as on 
windows, actually all code which try to move something using x,y 
coordinates  in user space should use this method.

On 21/05/2018 10:44, Phil Race wrote:
> Well I don't understand why that was put into SU2 either.
> Since it is also used just by the AWT Robot.
> It is from the fix for https://bugs.openjdk.java.net/browse/JDK-8176097
> 
> So I think these should both be moved out of SU2 and into Robot code.
> 
> -phil.
> 
> On 05/21/2018 10:16 AM, Sergey Bylokhov wrote:
>> 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.