On Wed, 20 Jan 2021 01:59:39 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> 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); >> 2) 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)); >> 3) 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? > >> 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. 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! ------------- PR: https://git.openjdk.java.net/jdk/pull/1907