Current threading model

Dear JOGL forum,

Is it still true that OpenGL calls have to be done from the AWT event thread, or has this been changed in recent years? I'm asking because my threading model could really benefit from being able to issue OpenGL calls directly without having to marshal values to and from the AWT thread.

Hi

The OpenGL calls must be done when the OpenGL context is current, that's all, it was already true at the very beginning of JOGL and it's still true nowadays. When you use GLEventListener and Animator, the OpenGL calls are done on the AWT event dispatching thread if and only if you use a canvas or a window relying on AWT, it's a bit different on NEWT.

It has been possible to perform OpenGL calls on other threads than the EDT for many years as long as the OpenGL context is current by making it current on those other threads, you can put those calls into GLRunnable instances and send them to the queue, see GLAutoDrawable.invoke(boolean, GLRunnable).

However, making the context current on another thread than the one on which the window has been created might be unsupported by some drivers.

Moreover, I don't see a huge benefit in a threading model, you cannot make the OpenGL context current on several threads at the same time. If you really expect something big from multi-threading in this case, there is probably something wrong in your code. A clean separation between what requires a current OpenGL context and what doesn't require it helps to perform only the necessary things when the OpenGL context is current and to perform the rest on multiple threads if possible.

What do you expect?

Maybe this helps:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLAutoDrawable.html#setExclusiveContextThread(java.lang.Thread)

gouessej wrote

The OpenGL calls must be done when the OpenGL context is current, that's all, it was already true at the very beginning of JOGL and it's still true nowadays.

I see. I was reading the "AWT Multithreading Issues" section on https://jogamp.org/jogl/doc/userguide/, which seemed to me to state that rendering literally had to be done on the event dispatch thread.

gouessej wrote

When you use GLEventListener and Animator, the OpenGL calls are done on the AWT event dispatching thread if and only if you use a canvas or a window relying on AWT

I'm not sure how to interpret this. Are you saying that, as long as I use AWT rather than NEWT, rendering has to be done on the EDT, or are you simply saying that rendering is done on the EDT as long as I use a GLEventListener or Animator? I do intend on using AWT under all circumstances.

gouessej wrote

However, making the context current on another thread than the one on which the window has been created might be unsupported by some drivers.

Yes, I did read on the above linked page that that was the main motivation for moving rendering onto the EDT, but that seems to be talking about the conditions back at the time of JOGL 1.1, which is quite some time ago. Are more modern drivers still having that problem? It's not a problem for me if it's just, say, Intel 915 drivers that don't handle this, as I don't intend to support anything older than OpenGL 2.0 anyway. Is there, by any chance, any data of any kind available about what kind of drivers have those kinds of issues?

gouessej wrote

Moreover, I don't see a huge benefit in a threading model, you cannot make the OpenGL context current on several threads at the same time.

Ah, yes, I'm well aware of that. I have two main reasons for wanting more explicit control over it. For one thing, my current rendering code already uses two threads: one for generating OpenGL commands (and buffering them in internal structures), and another one for actually dispatching those OpenGL commands to JOGL, so that these operations can operate in parallel. Obvious, only the latter thread needs the OpenGL context, and it would be much more convenient to not have to pass the data structures it needs over global variables to the EDT. The other reason is that it would be very convenient to be able to "inspect" the OpenGL context and just executing some simple glGet()s when setting up the UI, prior to making the AWT components visible and having any events dispatched to them.

The part starting with "All GLEventListener callbacks and other internal OpenGL context management are now performed on one thread" is still true. When you use NEWT, it has its own threads, it separates input management and OpenGL. When you use AWT, our implementation uses AWT to perform OpenGL calls but keep in mind that then you have to perform the OpenGL calls both on the AWT EDT and when the OpenGL context is current on this thread.

Yes, there are still this kind of issues in some more "modern" drivers, I had this problem again when I couldn't use a build-in mechanism of JOGL within JogAmp's Ardor3D Continuation, I wasted several weeks on this :s It seems to affect mainly Intel drivers under Windows but I can't be more accurate yet, I can't be 100% affirmative.

Nobody forces you to use global variables. If your commands are well designed as immutable objects, what's wrong with passing them to JOGL? You can already get some information without using glGet after the context has been property created and initialized.