<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