Hi, Semyon.
A few notes.
- The awtLock is a lowlevel lock which should be used only when we
access the xlib and some other native resource like opengl. We should
not call the users code on it. In the fix the code in
XDecoratedPeer.updateMinimumSize() will call the users code.
- Some of the changed methods are called already under this lock, for
example XDecoratedPeer.handlePropertyNotify(), and probably others.
On 18.10.16 16:46, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8167652
webrev: http://cr.openjdk.java.net/~ssadetsky/8167652/webrev.00/
In Linux, when a frame or dilalog is made resizable or non-resizable the
window decoration need to be updated. For that purpose window is
unmapped and mapped again and WM changes the window decoration parent.
The re-parenting may cause WM to send intermediate "artifact events"
which change the window location on the screen, this WM behavior is
undocumented. To avoid window move the window shift is compensated in
XWM.setShellResizable()/XWM.setShellNotResizable(), but Unity WM shifts
the window position in different way. In the proposed solution the
window shift compensation is adjusted for Unity WM.
Also in the fix all writes to the fields that store the current state of
window dimensions are protected with the AWT lock. This is necessary to
avoid unexpected window move or resize when the window dimensions are
changed from the user thread concurrently while the AWT toolkit thread
handles WM sent notifications affecting the current window state, size,
position, insets, etc.
--Semyon
--
Best regards, Sergey.
