Posted by Dolda2000 on Dec 13, 2017; 2:39pm
URL: https://forum.jogamp.org/Current-threading-model-tp4038405p4038415.html

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.