Thank you, Sergey!
Looking for the second +1 from someone else.
Thank you in advance,
Dmitry
On 24/03/2017 21:01, Sergey Bylokhov wrote:
Looks fine.
Hi Sergey,
Thank you for the review.
Actually deliverMoveResizeEvent() is always called once a window is displayed.
If the window is created using max W/H of the screen, the function will be
invoked and isZoomed field will contain the correct value. I have just checked
that.
Thanks,
Dmitry
On 23 Mar 2017, at 16:36, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote:
Hi, Dmitry.
Can you please check that the fix does not break the situation when the frame
is created using max W/H of the screen. In this case the old zoom logic return
true, is it possible that the new logic will return false since
deliverMoveResizeEvent
will not be called?
Hello,
Could you review a fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8176490
webrev: http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/
Problem description:
On OSX AppKit thread and EDT or main application thread might be blocked when a
child window is displayed and its parent is hidden at the same time. AppKit
thread performs windows ordering caused by displaying of the child window. It
retrieves child windows for the parent window and tries to acquire the monitor
inside Window.getOwnedWindows_NoClientCode(). However the monitor is already
owned by EDT/main application thread which executes setVisible(false) on the
parent window. That thread hangs on invocation of CWrapper.NSWindow.isZoomed()
since the function must be executed on AppKit thread.
Fix:
Add a new field isZoomed to CPlatformWindow class. The field will contain
information about current zoom state for the window. The method
deliverMoveResizeEvent() will update the new field using data from the
platform. The invocations of CWrapper.NSWindow.isZoomed() in CPlatformWindow
should be replaced with isZoomed field.
Note: I ran JCK tests on the build with fix and did not observe any new
problems.
Thanks,
Dmitry
