<AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on high DPI systems [v2]

[Olga Mikhaltsova]

On Wed, 20 Jan 2021 01:59:39 GMT, Sergey Bylokhov <serb at 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