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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Mar 22 01:48:39 UTC 2016


On 21.03.16 23:33, Alexandr Scherbatiy wrote:
>> 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.

Can you please confirm that the next two cases works properly:
- updateGC is called from the Win32GraphicsDevice.setFullScreenWindow(), 
is it correct to change the window bounds in this case? Is it possible 
that the window will exit the fullscreen?
- Can the updateGC+setBounds() moves the window to the second monitor => 
this will cause the updateGC+setBounds() again and move the window back 
to old screen and so on? (this is the case of two monitor configuration 
and the window in the middle).

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


-- 
Best regards, Sergey.


More information about the awt-dev mailing list