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