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

[Sergey Bylokhov]

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.
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>