<AWT Dev> [10] JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

<AWT Dev> [10] JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display

Shashidhara H V

Hi, Please review a fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8190326

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8190326/webrev.00/

(Please see from line no.83-87 for awt_Robot.cpp review and ignore other lines as they are under review for another bug)

 

Summary: Robot cursor move used to apply the primary monitor’s scaling factor to derive device coordinates even though there was move requested to another monitor having a different scaling factor. Now this is changed to use the logical point’s monitor scaling factor to which it may be moved to.

 

Thanks and regards,

Shashi

 

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [10] JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display

Sergey Bylokhov
Hi, Shashi
I think that the logic of how we use {x,y} coordinates in the users
space and how we convert them to device space should be similar for
robots API like mouseMove/getPixelColor/createScreenCapture and
Window.setBounds().
So it will be good to use the similar java code instaed of native code
for these cases, see WWindowPeer.setBounds()

ps: It seems that webrev contains a part of the fix from 8148344.


On 05/11/2017 21:34, Shashidhara Veerabhadraiah wrote:

> Hi, Please review a fix for the below bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190326
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8190326/webrev.00/
>
> (Please see from line no.83-87 for awt_Robot.cpp review and ignore other
> lines as they are under review for another bug)
>
> Summary: Robot cursor move used to apply the primary monitor’s scaling
> factor to derive device coordinates even though there was move requested
> to another monitor having a different scaling factor. Now this is
> changed to use the logical point’s monitor scaling factor to which it
> may be moved to.
>
> Thanks and regards,
>
> Shashi
>


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [10] JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display

Shashidhara H V
Hi Sergey, The problem is with using the wrong scaling for the cursor position. To explain:
        Primary Monitor res: 1920 * 1080 with scaling factor: 1.25 and a secondary monitor with res: 1600 * 1200 with scaling factor: 1.00.

When we pass a mouseMove(1921, 500) we would apply a scaling factor of 1.25 and calculate the device coordinates and send the mouse event. Currently this is the behaviour.
Actually we should be applying the secondary monitor’s scaling factor of 1.00(as this position is outside the primary monitor’s range) and then calculate the device coordinates and send the mouse event to move there. As you can see the diff in the awn_Robot.cpp(Only line nos. 83-87), previously we always used to use the primaryIndex(primary monitor) scaling factor. Now the scaling factor is updated to use the intended cursor move’s position of the respective monitor. So I do not think we can handle this by changing in the Java code than in the native code as the issue is with native code of the use of the wrong scaling factor.

Thanks and regards,
Shashi

> On 07-Nov-2017, at 2:08 AM, Sergey Bylokhov <[hidden email]> wrote:
>
> Hi, Shashi
> I think that the logic of how we use {x,y} coordinates in the users space and how we convert them to device space should be similar for robots API like mouseMove/getPixelColor/createScreenCapture and Window.setBounds().
> So it will be good to use the similar java code instaed of native code for these cases, see WWindowPeer.setBounds()
>
> ps: It seems that webrev contains a part of the fix from 8148344.
>
>
> On 05/11/2017 21:34, Shashidhara Veerabhadraiah wrote:
>> Hi, Please review a fix for the below bug.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190326
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8190326/webrev.00/
>> (Please see from line no.83-87 for awt_Robot.cpp review and ignore other lines as they are under review for another bug)
>> Summary: Robot cursor move used to apply the primary monitor’s scaling factor to derive device coordinates even though there was move requested to another monitor having a different scaling factor. Now this is changed to use the logical point’s monitor scaling factor to which it may be moved to.
>> Thanks and regards,
>> Shashi
>
>
> --
> Best regards, Sergey.

Reply | Threaded
Open this post in threaded view
|

Re: <AWT Dev> [10] JDK-8190326: Robot.mouseMove uses scaling factor of main display on unscaled second display

Sergey Bylokhov
On 07/11/2017 10:18, shashidhara veerabhadraiah wrote:
> Hi Sergey, The problem is with using the wrong scaling for the cursor position. To explain:
> Primary Monitor res: 1920 * 1080 with scaling factor: 1.25 and a secondary monitor with res: 1600 * 1200 with scaling factor: 1.00.
>
> When we pass a mouseMove(1921, 500) we would apply a scaling factor of 1.25 and calculate the device coordinates and send the mouse event. Currently this is the behaviour.
> Actually we should be applying the secondary monitor’s scaling factor of 1.00(as this position is outside the primary monitor’s range) and then calculate the device coordinates and send the mouse event to move there. As you can see the diff in the awn_Robot.cpp(Only line nos. 83-87), previously we always used to use the primaryIndex(primary monitor) scaling factor. Now the scaling factor is updated to use the intended cursor move’s position of the respective monitor. So I do not think we can handle this by changing in the Java code than in the native code as the issue is with native code of the use of the wrong scaling factor.

If I am not missing something, this is how WWindowPeer.setBounds() is
implemented? It finds the target GConfig and then does some math. Its a
generic algorithm for moving windows/cursors or taking a screenshot.

The Robot.createCompatibleImage()/WWindowPeer.setBounds() already use
this code:
gc = SwingUtilities2.getGraphicsConfigurationAtPoint()


--
Best regards, Sergey.