<AWT Dev> [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution
Alexandr Scherbatiy
alexandr.scherbatiy at oracle.com
Tue Oct 25 11:11:55 UTC 2016
Hello,
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
- the html test file is removed
Thanks,
Alexandr.
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.
>>>
>>
>>
>
More information about the awt-dev
mailing list