Re: JDK 9 b159 - sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns

[dmitry markov]

Hi Reto,

Thank you for the testcase. I was able to reproduce the problem using it.
I have opened JDK-8176490 
 for this issue. Will 
look into this.


Thanks,
Dmitry
On 09/03/2017 16:41, Reto Merz wrote:

Hi Dmitry,

I was able to create a demo to reproduce it.
It seems that the issue is triggered by Windows#setEnabled(boolean).

Steps to reproduce it with attached WindowTest.java,
maybe you need 2-3 attempts:

(0. start the demo program)
1. click on the button in the first window ; a second window opens
2. click on the button in the second dialog ; a third windows open
3. move the third window via mouse and click on the label
4. wait 9 seconds ; a fourth windows is opened (the fourth windows should be 
opened behind the third)
5. try to close the fourth
-> EDT is blocked

Attached threads_report.txt is a full thread dump after step 5.

FYI:
I just re-checked the logs, the original integration test was never run on 
macOS with a older JDK 9.
The original integration passes with:
- JDK 8 u152 EA on Windows and macOS
- JDK 9 b157 EA on Windows ; macOS not tested
- JDK 9 b159 EA on Windows ; hangs on macOS as described

Thanks
Reto



-Ursprüngliche Nachricht-
Von: dmitry markov [mailto:dmitry.mar...@oracle.com]
Gesendet: Donnerstag, 9. März 2017 08:52
An: Reto Merz
Cc: awt-dev@openjdk.java.net
Betreff: Re:  JDK 9 b159 -
sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns

Hi Reto,

I have no seen such hang before. Most likely this is a new issue.
Could you provide us with a test case, (i.e. reproducer), please? Once
we have a reproducer, I will open a bug for this.

Thanks,
Dmitry
On 07/03/2017 19:52, Reto Merz wrote:

Hi,

We have a integration test which hangs with Java 9 b159 under macOS
10.12.3.
It does not hang with b157 and also works with Windows OS & b159.
We can reproduce it always with our integration test.

I want to ask if this is already a known regression?
Otherwise I can try to provide a simple test case to reproduce it but
this would take some time.

The relevant thread stacks are:

"AWT-EventQueue-0" #13 prio=6 os_prio=31 tid=0x7fa86ea7e000
nid=0xd203 runnable [0x700010632000]
java.lang.Thread.State: RUNNABLE
 at
sun.lwawt.macosx.CWrapper$NSWindow.isZoomed(java.desktop@9-

ea/Native

Method)
 at
sun.lwawt.macosx.CPlatformWindow.isMaximized(java.desktop@9-

ea/CPlatformWindow.java:509)

 at
sun.lwawt.macosx.CPlatformWindow.setVisible(java.desktop@9-

ea/CPlatformWindow.java:558)

 at
sun.lwawt.LWWindowPeer.setVisibleImpl(java.desktop@9-

ea/LWWindowPeer.java:253)

 at
sun.lwawt.LWComponentPeer.setVisible(java.desktop@9-

ea/LWComponentPeer.java:763)

 at java.awt.Component.hide(java.desktop@9-ea/Component.java:1705)
 - locked <0x0007a48a2c20> (a java.awt.Component$AWTTreeLock)
 at java.awt.Window.hide(java.desktop@9-ea/Window.java:1118)
 at java.awt.Dialog.hide(java.desktop@9-ea/Dialog.java:1152)
 at java.awt.Window.hide(java.desktop@9-ea/Window.java:1110)
 - locked <0x0007a802e218> (a java.util.Vector)
 at java.awt.Dialog.hide(java.desktop@9-ea/Dialog.java:1152)
 at java.awt.Component.show(java.desktop@9-

ea/Component.java:1670)

 at
java.awt.Component.setVisible(java.desktop@9-

ea/Component.java:1615)

 at java.awt.Window.setVisible(java.desktop@9-ea/Window.java:1017)
 at java.awt.Dialog.setVisible(java.desktop@9-ea/Dialog.java:1005)

"AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x7fa87076b000
nid=0x307 waiting for monitor entry [0x7fff5e87e000]
java.lang.Thread.State: BLOCKED (on object monitor)
 at
java.awt.Window.getOwnedWindows_NoClientCode(java.desktop@9-

ea/Window.java:1478)

 - waiting to lock <0x0007a802e218> (a java.util.Vector)
 at
java.awt.Window$1.getOwnedWindows(java.desktop@9-

ea/Window.java:4127)

 at


sun.lwawt.macosx.CPlatformWindow.orderAboveSiblingsImpl(java.desktop
@9-ea/CPlatformWindow.java:1153)

 at


sun.lwawt.macosx.CPlatformWindow.orderAboveSiblings(java.desktop@9-
ea/CPlatformWindow.java:1118)

 at


sun.lwawt.macosx.CPlatformWindow.windowDidBecomeMain(java.desktop
@9-ea/CPlatformWindow.java:1182)

Thanks
Reto

Re: JDK 9 b159 - sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns

[Reto Merz]

Hi Dmitry,

I was able to create a demo to reproduce it.
It seems that the issue is triggered by Windows#setEnabled(boolean).

Steps to reproduce it with attached WindowTest.java,
maybe you need 2-3 attempts:

(0. start the demo program)
1. click on the button in the first window ; a second window opens
2. click on the button in the second dialog ; a third windows open
3. move the third window via mouse and click on the label
4. wait 9 seconds ; a fourth windows is opened (the fourth windows should be 
opened behind the third)
5. try to close the fourth
-> EDT is blocked

Attached threads_report.txt is a full thread dump after step 5.

FYI:
I just re-checked the logs, the original integration test was never run on 
macOS with a older JDK 9.
The original integration passes with:
- JDK 8 u152 EA on Windows and macOS
- JDK 9 b157 EA on Windows ; macOS not tested
- JDK 9 b159 EA on Windows ; hangs on macOS as described

Thanks
Reto


> -Ursprüngliche Nachricht-
> Von: dmitry markov [mailto:dmitry.mar...@oracle.com]
> Gesendet: Donnerstag, 9. März 2017 08:52
> An: Reto Merz
> Cc: awt-dev@openjdk.java.net
> Betreff: Re:  JDK 9 b159 -
> sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns
> 
> Hi Reto,
> 
> I have no seen such hang before. Most likely this is a new issue.
> Could you provide us with a test case, (i.e. reproducer), please? Once
> we have a reproducer, I will open a bug for this.
> 
> Thanks,
> Dmitry
> On 07/03/2017 19:52, Reto Merz wrote:
> > Hi,
> >
> > We have a integration test which hangs with Java 9 b159 under macOS
> > 10.12.3.
> > It does not hang with b157 and also works with Windows OS & b159.
> > We can reproduce it always with our integration test.
> >
> > I want to ask if this is already a known regression?
> > Otherwise I can try to provide a simple test case to reproduce it but
> > this would take some time.
> >
> > The relevant thread stacks are:
> >
> > "AWT-EventQueue-0" #13 prio=6 os_prio=31 tid=0x7fa86ea7e000
> > nid=0xd203 runnable [0x700010632000]
> >java.lang.Thread.State: RUNNABLE
> > at
> > sun.lwawt.macosx.CWrapper$NSWindow.isZoomed(java.desktop@9-
> ea/Native
> > Method)
> > at
> > sun.lwawt.macosx.CPlatformWindow.isMaximized(java.desktop@9-
> ea/CPlatformWindow.java:509)
> > at
> > sun.lwawt.macosx.CPlatformWindow.setVisible(java.desktop@9-
> ea/CPlatformWindow.java:558)
> > at
> > sun.lwawt.LWWindowPeer.setVisibleImpl(java.desktop@9-
> ea/LWWindowPeer.java:253)
> > at
> > sun.lwawt.LWComponentPeer.setVisible(java.desktop@9-
> ea/LWComponentPeer.java:763)
> > at java.awt.Component.hide(java.desktop@9-ea/Component.java:1705)
> > - locked <0x0007a48a2c20> (a java.awt.Component$AWTTreeLock)
> > at java.awt.Window.hide(java.desktop@9-ea/Window.java:1118)
> > at java.awt.Dialog.hide(java.desktop@9-ea/Dialog.java:1152)
> > at java.awt.Window.hide(java.desktop@9-ea/Window.java:1110)
> > - locked <0x0007a802e218> (a java.util.Vector)
> > at java.awt.Dialog.hide(java.desktop@9-ea/Dialog.java:1152)
> > at java.awt.Component.show(java.desktop@9-
> ea/Component.java:1670)
> > at
> > java.awt.Component.setVisible(java.desktop@9-
> ea/Component.java:1615)
> > at java.awt.Window.setVisible(java.desktop@9-ea/Window.java:1017)
> > at java.awt.Dialog.setVisible(java.desktop@9-ea/Dialog.java:1005)
> >
> > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x7fa87076b000
> > nid=0x307 waiting for monitor entry [0x7fff5e87e000]
> >java.lang.Thread.State: BLOCKED (on object monitor)
> > at
> > java.awt.Window.getOwnedWindows_NoClientCode(java.desktop@9-
> ea/Window.java:1478)
> > - waiting to lock <0x0007a802e218> (a java.util.Vector)
> > at
> > java.awt.Window$1.getOwnedWindows(java.desktop@9-
> ea/Window.java:4127)
> > at
> >
> sun.lwawt.macosx.CPlatformWindow.orderAboveSiblingsImpl(java.desktop
> @9-ea/CPlatformWindow.java:1153)
> > at
> >
> sun.lwawt.macosx.CPlatformWindow.orderAboveSiblings(java.desktop@9-
> ea/CPlatformWindow.java:1118)
> > at
> >
> sun.lwawt.macosx.CPlatformWindow.windowDidBecomeMain(java.desktop
> @9-ea/CPlatformWindow.java:1182)
> >
> > Thanks
> > Reto
> >

"AWT-EventQueue-0@1030" prio=6 tid=0xf nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 blocks AppKit Thread@973
  at sun.lwawt.macosx.CWrapper$NSWindow.isZoomed(CWrapper.java:-1)
  at 
sun.lwawt.macosx.CPlatformWindow.isMaximized(CPlatformWindow.java:509)
  at 
sun.lwawt.macosx.CPlatformWindow.setVisible(CPlatformWindow.java:558)
  at sun.lwawt.LWWindowPeer.setVisibleImpl(LWWindowPeer.java:253)
  at sun.lwawt.LWComponentPeer.setVisible(LWComponentPeer.java:763)
  at java.awt.Component.hide(Component.java:1705)
  - locked <0x848> (a java.awt.Component$AWTTreeLock)
  at java.awt.Window.hide(Window.java:1118)
  at java.awt.Dialog.hide(Dialog.java:1152)
  at 

Re: [9] Review request for 8175301 Java GUI hangs on Windows when Display set to 125%

[Alexander Zvegintsev]

+1

Thanks,
Alexander.

On 09/03/2017 13:48, Sergey Bylokhov wrote:

Looks fine.


  Hello,

Could you review the updated fix:
  http://cr.openjdk.java.net/~alexsch/8175301/webrev.01

There are two places where D3DSurfaceData.swapBuffers() is called 
D3DScreenUpdateManager.run() and D3DGraphicsConfig.flip(...).
D3DScreenUpdateManager.run()  uses the surface bounds which are already scaled.
D3DGraphicsConfig.flip(...) uses coordinates in the user space.

The fix converts the coordinates in the D3DGraphicsConfig.flip(...) to the 
device space and converts the coordinates to the user space in the 
D3DSurfaceData.swapBuffers() method to pass them to the repaint() method.

Thanks,
Alexandr.

On 3/7/2017 4:58 PM, Alexandr Scherbatiy wrote:

Hello,

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

  D3DSurfaceData.swapBuffers() is updated to scale passed bounds on HiDPI 
display.

Thanks,
Alexandr.

Re: [9] Review request for 8175301 Java GUI hangs on Windows when Display set to 125%

[Sergey Bylokhov]

Looks fine.

> 
>  Hello,
> 
> Could you review the updated fix:
>  http://cr.openjdk.java.net/~alexsch/8175301/webrev.01
> 
> There are two places where D3DSurfaceData.swapBuffers() is called 
> D3DScreenUpdateManager.run() and D3DGraphicsConfig.flip(...).
> D3DScreenUpdateManager.run()  uses the surface bounds which are already 
> scaled.
> D3DGraphicsConfig.flip(...) uses coordinates in the user space.
> 
> The fix converts the coordinates in the D3DGraphicsConfig.flip(...) to the 
> device space and converts the coordinates to the user space in the 
> D3DSurfaceData.swapBuffers() method to pass them to the repaint() method.
> 
> Thanks,
> Alexandr.
> 
> On 3/7/2017 4:58 PM, Alexandr Scherbatiy wrote:
>> 
>> Hello,
>> 
>> Could you review the fix:
>>  bug: https://bugs.openjdk.java.net/browse/JDK-8175301
>>  webrev: http://cr.openjdk.java.net/~alexsch/8175301/webrev.00
>> 
>>  D3DSurfaceData.swapBuffers() is updated to scale passed bounds on HiDPI 
>> display.
>> 
>> Thanks,
>> Alexandr.
>> 
> 

Re: [9] Review request for 8175301 Java GUI hangs on Windows when Display set to 125%

[Alexander Scherbatiy]

  Hello,

Could you review the updated fix:
  http://cr.openjdk.java.net/~alexsch/8175301/webrev.01

There are two places where D3DSurfaceData.swapBuffers() is called 
D3DScreenUpdateManager.run() and D3DGraphicsConfig.flip(...).
D3DScreenUpdateManager.run()  uses the surface bounds which are already 
scaled.

D3DGraphicsConfig.flip(...) uses coordinates in the user space.

The fix converts the coordinates in the D3DGraphicsConfig.flip(...) to 
the device space and converts the coordinates to the user space in the 
D3DSurfaceData.swapBuffers() method to pass them to the repaint() method.


Thanks,
Alexandr.

On 3/7/2017 4:58 PM, Alexandr Scherbatiy wrote:


Hello,

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

  D3DSurfaceData.swapBuffers() is updated to scale passed bounds on 
HiDPI display.


Thanks,
Alexandr.