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

[Alexandr Scherbatiy]

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