<AWT Dev> [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution

[Sergey Bylokhov]

Looks fine.

>  Hello,
> 
>  Could you review the updated fix:
>    http://cr.openjdk.java.net/~alexsch/8147440/webrev.03
> 
>  - InvokeFunction is used to call the _WindowDPIChange in the AWT Window on native level.
>  - WWindowPeer.windowDPIChange(...) is called only if the previous device screen is different from the new one.
> 
> Thanks,
> Alexandr.
> 
> On 2/3/2017 9:32 PM, Sergey Bylokhov wrote:
>> Hi, Alex.
>> Is it intentional that «WindowDPIChange» can be called twice in some cases:
>> First:  CheckIfOnNewScreen()-> draggedToNewScreen->displayChanged()->checkDPIChange(newDev)
>> Second:  CheckIfOnNewScreen()->WindowDPIChange(prevScrn, curScrn);
>> 
>> I am not sure but it looks like they can be executed in parallel, because the first case will be called on EDT, and the second will be called on toolkit.
>> 
>>> 
>>> Hello,
>>> 
>>> Could you review the updated fix:
>>>  http://cr.openjdk.java.net/~alexsch/8147440/webrev.02
>>> 
>>>  - changing window size according to DPI when a window is moved from one display to another is added
>>>  - window size updating is moved to the native side
>>> 
>>>  Thanks,
>>>  Alexandr.
>>> 
>>> On 10/25/2016 5:32 PM, Sergey Bylokhov wrote:
>>>> On 25.10.16 14:11, Alexandr Scherbatiy wrote:
>>>>>  Could you review the updated fix:
>>>>>    http://cr.openjdk.java.net/~alexsch/8147440/webrev.01/
>>>>>  - an undecorated frame does not set WWindowPeer.sysX/Y/W,H values so
>>>>> the fix is updated to retrieve a window bounds form the target
>>>> Why this fields is not updated for undecorated frame? We should carefully use target here, on what thread this callback is executed?
>>>> 
>>>> Can you also check the situation when on multi-monitor configuration you will move the window from one screen to another(both screens should have different scale). Is it possible that you will get updateGC -> then you call setBounds -> increase the size of window -> this will move the window to other screen->updateGC-> setBounds->decrease the size of the window, etc?
>>>> 
>>>> 
>>>>> On 3/21/2016 11:33 PM, Alexandr Scherbatiy wrote:
>>>>>> 
>>>>>> On 2/10/2016 5:32 AM, Sergey Bylokhov wrote:
>>>>>>> On 05.02.16 10:52, Alexandr Scherbatiy wrote:
>>>>>>> 
>>>>>>>>   The first approach is to rescale only frame size on native level so
>>>>>>>>     newNativeWindow.size = newScale *  javaWindow.size
>>>>>>> What location will be in this approach?
>>>>>>    The idea was to update WComponentPeer.setBounds(x,y, w, h) method
>>>>>> that it sets only size for the op=SET_BOUNDS on the native level.
>>>>>>    In this case the native window location and java window location
>>>>>> will not be changed.
>>>>>>    However, the relation between newNativeWindow.location and
>>>>>> javaWindow.location will use the old scale factor instead the new one.
>>>>>> 
>>>>>>> Does the native app work in the similar way(changes the size only)?
>>>>>>    Yes. The native application changes their size but leaves the
>>>>>> location the same.
>>>>>> 
>>>>>>  Thanks,
>>>>>>  Alexandr.
>>>>>> 
>>>>>>>>   This allows to leave the nativeWindow.location unchanged but the
>>>>>>>> rule
>>>>>>>>     nativeWindow.location = newScale * javaWindow.location
>>>>>>>>   will be broken in this case.
>>>>>>>> 
>>>>>>>>   The proposed fix explicitly rescales javaWindow.location in
>>>>>>>> WWindowPeer so
>>>>>>>>   nativeWindow.location = prevScale * prevJavaWindow.location =
>>>>>>>> newScale * newJavaWindow.location
>>>>>>>> 
>>>>>>>>  Thanks,
>>>>>>>>  Alexandr.
>>>>>>>> 
>>>>>>> 
>>>> 
>