<AWT Dev>  Review Request: 8196030 and 8190326
Sergey.Bylokhov at oracle.com
Mon May 21 17:16:56 UTC 2018
This method call getGraphicsConfigurationAtPoint() which is located in
the SwingUtilities2 and the robot class already depends on it:
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.
> On 05/18/2018 12:38 PM, Sergey Bylokhov wrote:
>> Please review the fix for jdk11.
>> 8196030: AWT Robot mouseMove fails on Windows 10 1709 with HiDPI
>> 8190326: Robot.mouseMove uses scaling factor of main display on
>> unscaled second display
>> Webrev: http://cr.openjdk.java.net/~serb/8196030/webrev.04
>> 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
>> (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
>> - 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
>> - 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.
>>  https://bugs.openjdk.java.net/browse/JDK-4288230
Best regards, Sergey.
More information about the awt-dev