JOGL & JAWT Surface Change Semantics

Hello,

Recent testing within an MDI environment (JDesktopPane) brought to light one interesting fact. GLEventListener.init gets called every time the JInternalFrame which contains a GLCanvas loses focus to another JInternalFrame. Upon regaining the focus, previous JInternalFrame aparently has changed its surface since JOGL reissues GLEventListener.init for said GLCanvas. From reading other threads, initially I understood this only being the case with GLJPanel, however it appears to affect GLCanvas as well.

Since surface change semantics (JAWT_LOCK_SURFACE_CHANGED) forces JOGL to recreate the GL context, it also forces all associated listeners to reinitialize. (and although its possible to keep state and reinitialize when its done, I’m looking at only doing initializaiton once)

Is there any way to avoid this, or is this even the correct behaviour wrt JDesktopPane?

If the JDesktopPane has only one JInternalFrame present, consequently said internal frame does not lose focus, surface does not change. However, as soon as another JInternalFrame is added, previous JInternalFrame can no longer maintain its current surface.

I’ve looked at the way JOGL handles this scenario, and it appears that JOGL basically gets the information about surface change from JAWT during context activation, and recreates the GL context when surface has changed.

Is there any way, native or otherwise I can work around this problem? Such as forcing native peer to hold on to the current surface.

Bug-ID [4347021] (JAWT : Multi-threading issues with changing state) indicates that some state tracking bug exists wrt JAWT surfaces, and is only being fixed in Mustang. I’m using build 61 currently, and although I’m not entirely sure as to the root of this problem, before I investigate further, I was wondering if anyone has came across this.

Thank you, for any insight.

I noticed similar behavior with JInternalFrames in 1.4.2 but found it to be fixed in 1.5.0. Do you have a small test program which shows that this problem is still present in Mustang? The problem wasn’t related to the JAWT, but that the JInternalFrames were causing addNotify / removeNotify to be called on their children when the focus changed.

Since I’ve encountered this problem, and due to time constraints, instead of investigating further just yet, I went ahead and did re-initialize every time GLContext gets destroyed. As I’ve moved on to other things, again, due to time constraints, I’ve de-prioritized this issue as its not a show-stopper just yet.

I’m definitely not done with it however, and as soon as I get another chance (hopefully next weekend), I will dig deeper and see if I can override some of the JDesktopPane behaviour to prevent this from happening. (I kind guessed it had to do with revalidation of the container, but currently can’t check it out further)

As for extracting small test case, I can do it, but I would rather just post an entire solution once I get the time to take a look at it.

Thanks for info.

Attached is the test case source.

Tested: 1.4.2_08, 1.5.0_05, 1.6.0-rc (b61).