<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