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.
