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

[Alexander Zvegintsev]

+1

--
Thanks,
Alexander.

On 02/08/2017 07:59 PM, Sergey Bylokhov wrote:
> 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.
>>>>>>>>>