Posted by Alexis Drogoul on Mar 27, 2015; 2:29am
URL: https://forum.jogamp.org/Hangs-and-Freezes-JOGL-2-2-4-2-3-0-MacOS-X-Yosemite-JDK-6-7-8-SWT-3-8-2-4-4-2-tp4034199.html

Hi all,

First of all, thanks to all the developers of JOGL. We've been relying on this library since 5 years for the GAMA platform (http://gama-platform.org) and, although it has been sometimes "tough" to deal with threading issues or rendering problems (since we combine AWT, SWT & JOGL in the same product), I musth say that I have been impressed by the robustness of JOGL. That is, until we decided (at last) to move from the old, deprecated JOGL 1.1 version to the "new" 2.x stream. We hadn't made the move before (despite several attempts last year) mainly because of human resources problems: finding someone skilled in OpenGL + AWT + Eclipse RCP was not completely evident and our resources are anyway limited.

Because we are bound to deliver a new version this summer, we decided to tackle this issue by ourselves now.

First of all, a word about the rendering subsystem of the platform: the general UI is based on Eclipse RCP (we havent made the move yet to the e4 stream, so we use Eclipse 3.8.2, although this may change in the following months), but, for performance reasons, we have a rendering based on Java2D (the "regular" displays, which allow small computer to run simulations) and/or OpenGL (using, thus, JOGL 1.1). Both displays rely on a somewhat "improved" version of the SWT_AWT bridge (another choice motivated by performances, as Draw2D is unbearably slow and the SWT GLCanvas was completely buggy at that time). Although highly acrobatic, this combination worked quite well for the last 4 versions of GAMA and our ~2000 users, who work on the 3 main OSes (MacOS X, Windows and Ubuntu).

Moving the OpenGL part of the rendering subsystem to the new JOGL libraries was not as painful as we thought (at least from a compilation point of view). The APIs have changed a bit, but nothing too complicated, and, soon, we had a "working" environment based on JOGL 2.2.4. Needless to say, it didn't work using the SWT_AWT bridge, and that is the first problem i want to report: without changing anything to our setup (beside the libraries and the adaptation to their API), all we obtained were gray displays or, somewhat randomly, working displays and gray ones side by side, but the working ones would freeze as soon as we resized a view. The logging of JOGL would reveal that the gray displays were considering the Canvas as not ready ("FPSAWTAnimator#00-Timer0: Info: GLCanvas display - skipped GL render, drawable not valid yet"), although they could be made "ready" by minimizing/maximizing the views several times in a row. The frozen ones, however, did not display anything, as if the animator had been deactivated somehow (no dispose message, nothing). A bit frustrating, to say the least.

Since JOGL has made tremendous progresses in supporting the SWT environment, we then decided to try out a pure SWT-based view for rendering OpenGL displays. I derived an "SWT" view based on the JOGL SWT GLCanvas, and tested the following combinations (only on MacOS X Yosemite, but we anyway need to have GAMA working on the 3 environments, on a 2011 17" MacBook Pro):

- JDK 1.6 (the latest from Apple), JOGL 2.2.4 & 2.3, SWT 3.8.2.
- JDK 1.7u76 (the latest 1.7 from Oracle), JOGL 2.2.4 & 2.3, SWT 3.8.2.
- JDK 1.8u25 (the latest 1.8 from Oracle), JOGL 2.2.4 & 2.4, SWT 3.8.2
- + all the above with a mixture of Eclipse 3.8.2 & SWT 4.4.2 (the latest from Eclipse).

Not all combinations worked flawlessly, but they did at least display something, which was already great news (no more fiddling with AWT/SWT inter threading issues !). However, they *all* showed the exact same problem, which is the main reason why I decided to write this (long) message:

1) The initialization of OpenGL is slow. The UI is blocked something like 1 or 2 seconds, while it is much faster using the AWT based views. I dont understand why, as this initialization has normally nothing to do with AWT or SWT. One reason could be that GLProfile.initSingeton() is called as soon as we open an OpenGL display, and maybe it's blocking the SWT thread and not the AWT one. I did not investigate more, and I could benchmark this, probably, by explicitly calling initSingleton() in a different thread, but this issue is not a priority right now.

2) Closing a view (either by hand or programmatically, when switching to a different model or simulation or relaunching a simulation) blocks the UI for 5 to 10 seconds, with the closing OpenGL viewpart being emptied, then shown during this period, until it is closed and another one is opened. The logs show in all cases the exact same messages: "java.lang.RuntimeException: Waited 5000ms for: …" after a call to lockSurface() by the animator thread + a stack trace corresponding to the various dispose() calls (from the ViewPane to the GLCanvas). I've tried to stop the animator first, do some preliminary dispose() of various components, destroy the context, etc. with no luck. Disposing a view containing a JOGL SWT GLCanvas always hangs (and this is a pity, since the view works quite well…). I just noticed that this behavior does not happen if we simply open a view, obtain the first displaying of the model (the animator is anyway running behind), do not run the simulation (i.e. no wiping, no replacement of the displayed objects occur) and then close it. As if having some "contents" in the view would prevent the view from closing.

3) Closing the application freezes it if an OpenGL part is still open. The same message is displayed, but then nothing happens and I have to force-quit it.

Pretty frustrating as I was quite close to the goal ! Now, I dont expect the members of the forum to magically solve this problem as it is clearly not a proper issue report. GAMA is a complex platform and it is perfectly possible that some of our design choices are the causes of this disappointing behavior.

Instead, I would like to have advices on how to test this progressively. In the light of what I have exposed, what kind of repeatable benchmark should I try to run to eliminate the different causes of this behavior. Are there some available in the test units of JOGL ? A simple setup with the JOGL SWT GLCanvas that I could try and then progressively complexify by myself ?

Also, does this report make sense for other users/developers of JOGL ? Sometimes, simply mentioning a similar problem can shed a light on a part of the software I hadn't thought about before.

Advices on how to proceed to obtain a working SWT-based OpenGL view are however what I expect the most, and I thank you in advance for your comment !

Cheers
Alexis