Created attachment 739 [details] A java class with main method to demo explained behaviour. We have a GLCanvas, working very well until some other AWT component calls Thread.currentThread.interrupt() (for whatever reason) during paint method execution. Afterwards GLCanvas doesn't get updated on the screen even though it's display(glad) method is executed completely.
can be an intel chipset problem :(
commit 3235a4ae91e0202f9a36b8df4893f83be129dea2: Unit test to validate that Thread.interrupt() does not disturb continued rendering of AWT and GLCanvas. This test is based on your attached test case. Tests are displaying an ever color rotating rectangle in an AWT component alone and with an additional GearsES2 within a GLCanvas. The AWT component is issuing an interrupt during paint on the AWT-EDT. The reporter claims that an interrupt on the AWT-EDT shall not disturb neither AWT nor JOGL's GLCanvas and rendering shall continue. This seems to be true. The test passes on GNU/Linux and Windows using JRE 1.8.0_60. +++ Hence, I cannot reproduce this issue here.
(In reply to Sven Gothel from comment #2) Hi Sven, did you have a chance to try it on intel graphics platform?
com.jogamp.opengl.test.junit.jogl.awt.TestBug1225EventQueueInterruptedAWT hangs w/ java 1.7.0_45
commit 45448a1bcdca7a5d7605de072fb39c8c31afc00f Make unit test more robust, notify if JRE 1.7.0 issue w/ interrupted AWT-EDT The reporter claims that an interrupt on the AWT-EDT shall not disturb neither AWT nor JOGL's GLCanvas and rendering shall continue. - This seems to be true for JRE 1.8.0_60 - This seems to be false for JRE 1.7.0_45. This JRE's AWT-EDT even dies occasionally when interrupted. On both JRE's occasionally an interrupt could be detected on the AWT-EDT w/ or w/o GLCanvas being used. On JRE 1.7.0_45 GNU/Linux, the AWT-EDT even dies while not using GLCanvas (1st test). The behavior differs depending on the machine. Hence this test case purpose is more to document the different AWT-EDT behavior on the running machine / JRE version.