On Tue, 29 Dec 2020 20:56:06 GMT, Olga Mikhaltsova <omikhaltc...@openjdk.org> wrote:
> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on! > > This bug is due to the following reason: while scaling Java recalculates > resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and > works inside these new coordinates but at the same time the events, that come > from the system, continue reporting positions in the old coordinates (W x H). > > The idea of the suggested fix is in division of coordinates on the scale when > they come from the system to Java and multiplying them on the scale when they > go back from Java to the system. It is similar to processing events from > mouse and buttons. > > Testing is quite complicated because for reproducing this bug the following > conditions should be met: > 1. HiDPI is turned on > 2. sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100% > 3. the source of drag-n-drop is non-java application > > The step-by-step guide how to reproduce this bug is added to > https://bugs.openjdk.java.net/browse/JDK-8257414. src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 616: > 614: /* Translate mouse position from root coordinates > 615: to the target window coordinates. */ > 616: Point p = xwindow.toLocal(xwindow.scaleDown(x), > xwindow.scaleDown(y)); I guess some clarification here is required. It is unclear what the coordinate system is used by the x/y above. Looks like before the fix the device space was always used, and after the fix the mix of device/user's space will be used. If the user's space should always be used(the scaled version of the device), then I suggest to scale these coordinates here: x = (int)(xclient.get_data(2) >> 16); y = (int)(xclient.get_data(2) & 0xFFFF); But you will need to check that all usage of the new coordinate system will be valid across the method. ------------- PR: https://git.openjdk.java.net/jdk/pull/1907
