Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8143316/webrev.01
- DefaultMouseInfoPeer is removed from the SunToolkit and
WMouseInfoPeer is added to the WToolkit
- Screen devices initialization is added to the WMouseInfoPeer
- MONITOR_DEFAULTTONEAREST argument is changed to the
MONITOR_DEFAULTTOPRIMARY for the MonitorFromPoint method
to find a point which is not contained within any display monitor.
On 12/23/2015 5:59 PM, Sergey Bylokhov wrote:
Hi.
This issue is related to windows only, but we change the shared code
in a way which can mislead someone, and the crash can be returned
after some refactoring, or when someone will call
fillPointWithCoords() before device initialization in some other place.
So it seems this code should be rewritten, am I missed something but
it looks like this method incorrectly work in case of scaled displays.
I guess fillPointWithCoords should return unscaled coords otherwise
how we will figure out what scale should be used there(screen)?
Because at the end of the method getPointerInfo we iterate over
devices to find which one is correct.
Windows and Mac OS X use different strategies to return the mouse
coordinates.
CGEventGetLocation function returns scaled mouse coordinates on Mac
OS X.
GetCursorPos function returns unscaled mouse coordinates on Windows.
It looks like it is better to always return scaled coordinates from
the native level.
Thanks,
Alexandr.
On 10/12/15 15:06, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8143316
webrev: http://cr.openjdk.java.net/~alexsch/8143316/webrev.00
The the native MouseInfo.fillPointWithCoords() method can access the
devices before they are initialized.
The fix moves the devices initialization before the
getMouseInfoPeer().fillPointWithCoords(point) call in the
getPointerInfo() method.
The MonitorFromPoint method is added to the native
fillPointWithCoords() method to find the device where the mouse cursor
is placed.
Thanks,
Alexandr.
