Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

8257414: Drag n Drop target area is wrong on high DPI systems #1907

Closed
wants to merge 3 commits into from
Closed

8257414: Drag n Drop target area is wrong on high DPI systems #1907

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ab3eb6a
8257414: Drag n Drop target area is wrong on high DPI systems
omikhaltsova Dec 29, 2020
e4c1c73
8257414: Drag n Drop target area is wrong on high DPI systems
omikhaltsova Feb 2, 2021
d8259bd
8257414: Drag n Drop target area is wrong on high DPI systems
omikhaltsova Feb 12, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java
View file
Open in desktop
Expand Up @@ -613,7 +613,7 @@ private boolean processXdndPosition(XClientMessageEvent xclient) {
if (xwindow != null) {
/* Translate mouse position from root coordinates
to the target window coordinates. */
Point p = xwindow.toLocal(x, y);
Point p = xwindow.toLocal(xwindow.scaleDown(x), xwindow.scaleDown(y));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sergey, thank you! Could you give me a hint please concerning some use case of drag-and-drop to meet the (xwindow == 0) condition in XDnDDropTargetProtocol::processXdndPosition(..)? I'm unable to do it by means of the tests' apps I have.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sergey, thank you! Could you give me a hint please concerning some use case of drag-and-drop to meet the (xwindow == 0) condition in XDnDDropTargetProtocol::processXdndPosition(..)? I'm unable to do it by means of the tests' apps I have.

I think it is somehow related to the embedded frame when the event comes from some native window that is not registered as a java peer(but some external native app/window)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I failed to test branches of XDnDDropTargetProtocol::processXdndPosition(..) under condition (xwindow == null) by means of EmbeddedFrame. In addition none of automatic regression tests (test/jdk/java/awt/dnd/, test/jdk/java/awt/xembed/, test/jdk/sun/awt) gets into these branches.

I also tried to scale coordinates (as you advised) right after:

        x = (int)(xclient.get_data(2) >> 16);
        y = (int)(xclient.get_data(2) & 0xFFFF);

as follow:

GraphicsConfiguration gc = GraphicsEnvironment
                .getLocalGraphicsEnvironment()
                .getDefaultScreenDevice()
                .getDefaultConfiguration();
        gc = SunGraphicsEnvironment.getGraphicsConfigurationAtPoint(gc, x, y);
        GraphicsDevice device = gc.getDevice();
        if (device instanceof X11GraphicsDevice) {
            int scale = ((X11GraphicsDevice) device).getScaleFactor();
            x = XlibUtil.scaleDown(x, scale);
            y = XlibUtil.scaleDown(y, scale);
        }

but found out that getGraphicsConfigurationAtPoint() also requires the already scaled coordinates.

There are 3 different places in XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to decide whether to scale coordinates or not:

  1. I'm not sure and I'm unable to test it:
if (xwindow == null)
        {
            long receiver =
                XDropTargetRegistry.getRegistry().getEmbeddedDropSite(
                    xclient.get_window(), x, y);
  1. I'm quite sure and I'm able to test it:
if (xwindow != null) {
            /* Translate mouse position from root coordinates
               to the target window coordinates. */
            Point p = xwindow.toLocal(xwindow.scaleDown(x), xwindow.scaleDown(y));
  1. I think that scaling is necessary but I'm unable to test it (additionally the question raises concerning this case, why the coordinates are not converted to local here similar to the 2 case):
if (xwindow == null) {
            if (targetXWindow != null) {
                notifyProtocolListener(targetXWindow, x, y,
                                       DnDConstants.ACTION_NONE, xclient,
                                       MouseEvent.MOUSE_EXITED);

Sergey, is it possible at the moment to fix the particular issue and leave the other use cases to work as it works before due to no possibility to test them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 3 different places in XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to decide whether to scale coordinates or not:

Unfortunately, this is the purpose of the whole fix to decide when the scale is required and then not, otherwise we can simply break the untested cases.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sergey, please, review my last changes! Finally I managed to check all necessary branches in XDnDDropTargetProtocol::processXdndPosition(..). The user's space (the scaled version of the device) must be used everywhere here. I had to devide scaling according to condition (xwindow != null) in order to use more simple and fast realization for most of cases. The scaling for the case (xwindow == null) related to the embedded frame is based on the idea that there is only one pointer (cursor) in the system and it is used for drag-n-drop operation. I tried different ways to get scale in the last case but only this one is workable. If you have some better idea, tell me, please, another way to do it!

x = p.x;
y = p.y;
}
Expand Down
8 changes: 4 additions & 4 deletions src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java
View file
Open in desktop
Expand Up @@ -524,17 +524,17 @@ private void processMouseMove(XMotionEvent xmotion) {
updateTargetWindow(xmotion);

if (dragProtocol != null) {
dragProtocol.sendMoveMessage(scaleDown(xmotion.get_x_root()),
scaleDown(xmotion.get_y_root()),
dragProtocol.sendMoveMessage(xmotion.get_x_root(),
xmotion.get_y_root(),
sourceAction, sourceActions,
xmotion.get_time());
}
}

private void processDrop(XButtonEvent xbutton) {
try {
dragProtocol.initiateDrop(scaleDown(xbutton.get_x_root()),
scaleDown(xbutton.get_y_root()),
dragProtocol.initiateDrop(xbutton.get_x_root(),
xbutton.get_y_root(),
sourceAction, sourceActions,
xbutton.get_time());
} catch (XException e) {
Expand Down