Quantcast

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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy

  Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8147440
   webrev: http://cr.openjdk.java.net/~alexsch/8147440/webrev.00/

   When Display DPI is changed the Windows OS rescales a native window
size but leaves a native window location the same.
   Java frame size and location are calculated as
     nativeWindow.location = scale * javaWindow.location
     nativeWindow.size = scale * javaWindow.size

   The first approach is to rescale only frame size on native level so
     newNativeWindow.size = newScale *  javaWindow.size
   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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

alexander stepanov
Hello Alexandr,

WRT WindowResizingOnDPIChangingTest - I have quite similar manual test
on review:
http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
(but it requires two-display configuration).

Could these tests coexist later on? I hope they are not full duplicates.

(and now we come here, could please anyone review it?)

Thanks,
Alexander



On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:

>
>  Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8147440
>   webrev: http://cr.openjdk.java.net/~alexsch/8147440/webrev.00/
>
>   When Display DPI is changed the Windows OS rescales a native window
> size but leaves a native window location the same.
>   Java frame size and location are calculated as
>     nativeWindow.location = scale * javaWindow.location
>     nativeWindow.size = scale * javaWindow.size
>
>   The first approach is to rescale only frame size on native level so
>     newNativeWindow.size = newScale *  javaWindow.size
>   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.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy
On 05/02/16 12:59, Alexander Stepanov wrote:
> Hello Alexandr,
>
> WRT WindowResizingOnDPIChangingTest - I have quite similar manual test
> on review:
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
> (but it requires two-display configuration).
>
> Could these tests coexist later on? I hope they are not full duplicates.
   Yes, the MultiDisplayTest always requires at least 2 display but
WindowResizingOnDPIChangingTest can be used for display DPI changing
only on one monitor. I think they both can coexist.

   Thanks,
   Alexandr.

>
> (and now we come here, could please anyone review it?)
>
> Thanks,
> Alexander
>
>
>
> On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:
>>
>>  Hello,
>>
>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8147440
>>   webrev: http://cr.openjdk.java.net/~alexsch/8147440/webrev.00/
>>
>>   When Display DPI is changed the Windows OS rescales a native window
>> size but leaves a native window location the same.
>>   Java frame size and location are calculated as
>>     nativeWindow.location = scale * javaWindow.location
>>     nativeWindow.size = scale * javaWindow.size
>>
>>   The first approach is to rescale only frame size on native level so
>>     newNativeWindow.size = newScale *  javaWindow.size
>>   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.
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

alexander stepanov
Thanks!

On 2/5/2016 1:55 PM, Alexander Scherbatiy wrote:

> On 05/02/16 12:59, Alexander Stepanov wrote:
>> Hello Alexandr,
>>
>> WRT WindowResizingOnDPIChangingTest - I have quite similar manual
>> test on review:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html
>> (but it requires two-display configuration).
>>
>> Could these tests coexist later on? I hope they are not full duplicates.
>   Yes, the MultiDisplayTest always requires at least 2 display but
> WindowResizingOnDPIChangingTest can be used for display DPI changing
> only on one monitor. I think they both can coexist.
>
>   Thanks,
>   Alexandr.
>>
>> (and now we come here, could please anyone review it?)
>>
>> Thanks,
>> Alexander
>>
>>
>>
>> On 2/5/2016 10:52 AM, Alexandr Scherbatiy wrote:
>>>
>>>  Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8147440
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8147440/webrev.00/
>>>
>>>   When Display DPI is changed the Windows OS rescales a native
>>> window size but leaves a native window location the same.
>>>   Java frame size and location are calculated as
>>>     nativeWindow.location = scale * javaWindow.location
>>>     nativeWindow.size = scale * javaWindow.size
>>>
>>>   The first approach is to rescale only frame size on native level so
>>>     newNativeWindow.size = newScale *  javaWindow.size
>>>   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.
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sergey Bylokhov
In reply to this post by Alexandr Scherbatiy
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? Does the native app work in the
similar way(changes the size only)?

>    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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sergey Bylokhov
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy
In reply to this post by Alexandr Scherbatiy

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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


--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandr Scherbatiy

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Loading...