So I understand that it is considered bad practice to multithread openGL calls. However, I’m making an application where I have separate Drawables and Contexts, and let’s just say each one is in its own Frame. Is there any significant overhead to having a separate animator for each Drawable, which essentially multithreads the openGL calls while still satisfying the conditions: each context is in at most 1 thread, and each thread has at most 1 active context. Should I be managing the calls manually and looping through each context and drawing to it sequentially? Thanks.
If you’re using the standard JOGL Animator and GLEventListener mechanism, then having a separate Animator per Drawable won’t multithread your OpenGL work. Behind the scenes, the GLCanvas and GLJPanel both move the OpenGL work onto the AWT Event Dispatch Thread. We have found from experience that doing this is the only way to achieve robustness on a wide range of graphics cards and OpenGL driver versions. There are ways to defeat this (for example, by calling Threading.disableSingleThreading()) but I would not recommend it. Instead, I would recommend just using one Animator and adding all of your GLAutoDrawables to it.
I haven’t checked, so pardon my asking if it’s obvious, but is it possible to change which thread the opengl code gets shoveled off to. I’m perfectly fine using only 1 thread for opengl work, but I might like at some point to not block the AWT thread as much.
If you’re not using JOGL’s Animator and GLEventListener classes, then choosing a thread to become your rendering thread is up to your app. Otherwise, I imagine you’ll have to make some source code modifications to JOGL, or even the JDK.
There was a discussion about this some time ago and rendering was switched to a dedicated worker thread per default for some beta-releases. This turned out to be problematic on some cards/drivers/systems, so rendering was switched back to the AWT Event Thread. AFAIK you can still enable the worker thread by specifying “-Dopengl.1thread=worker” on the command line. See https://jogl.dev.java.net/issues/show_bug.cgi?id=191 and http://www.java-gaming.org/forums/index.php?topic=13421.0 for details.
I’d like to write my own thread manager, but I like the functionality of the GLEventListener. I’m guessing it’s unsafe to use the eventlistener without using the animator, since the GLEventListener runs it’s methods on the AWT thread, but I’m calling display() from my own thread. I like the reshape functionality of the listener, though. Is this just called from the resizing event listener of the Frame? I can just implement my own in that case.
We found that performing the GLEventListener.reshape() callback during the actual AWT reshape operation was problematic, since the AWT tree lock is held during that operation, so we defer the sending of the reshape call until the next render() / display(). You can always look at the source code for the GLCanvas and GLDrawableHelper to see how they’re implemented, and you can also write your own custom components; you don’t have to use the GLCanvas.