Rendering from a different thread

I’m writing an offline, non-realtime renderer. It creates a GLPbuffer, and uses that to do the rendering. Although this works, there’s one aspect I’m unhappy about. No matter what thread I call display() on, the GLEventListener gets invoked on the event dispatch thread, and I have to do all my rendering within that listener. This means that the event thread (and hence the whole UI) is blocked for as long as it takes to render, which is potentially a long time.

Here are some things that may be significant:

  1. I’m doing all the rendering in a GLPbuffer. It doesn’t interact with the UI in any way.

  2. The pbuffer’s GLContext is not shared with anything else.

  3. This is not the only use of JOGL in this application, so I need to address it in a way that doesn’t mess up other parts of the application (by changing global settings).

The Threading class might be a solution except for the last point. It only offers global settings that change the behavior of the entire application. Also, disableSingleThreading() isn’t even guaranteed to have an effect on all platforms.

So is there any way that, just for this one pbuffer and GLContext, which has no connection to any other use of OpenGL or anything in the UI, I can do rendering from a different thread?

Peter

No replies after two days. Am I trying to do something that simply isn’t possible with JOGL? Should I look into a different OpenGL wrapper?

Peter

Yup, I think you pretty much got stuck there with JOGL.

However, you can spread your rendering calls over multiple display() invocations, keeping your UI responsive … ?

Does LWJGL support opengl calls from other threads (as long as it makes a context current)?

Yes

Will there be any problems if I use both JOGL and LWJGL in a single application? I’m also using OpenGL for other things in this program, for which LWJGL isn’t suitable. They wouldn’t be directly interacting: I’d use JOGL for all the on-screen rendering, and LWJGL for rendering to a single pbuffer. I just want to make sure they won’t interfere with each other simply by both getting invoked within the same application.

Peter

There is a good reason for the GLPbuffer (and the other JOGL GLDrawables) doing its work on the EDT – it improves stability over a range of graphics cards.

That having been said, you can disable this behavior by calling javax.media.opengl.Threading.disableSingleThreading() at the beginning of your app. Note that this will also affect the behavior of the GLCanvas, so if you want to continue to do its work on the EDT you’ll have to manually invoke its display() method on the EDT at that point.

LWJGL fanatics, please keep the JOGL bashing off this forum.

So you’re saying that if I call disableSingleThreading(), the only effect is to cause the listener to be invoked from whatever thread I called display() on? And as long as I make sure I only ever call display() on my GLCanvases from the EDT, they’ll continue to behave exactly as they have? If so, I can work with that.

[quote=“Ken Russell,post:7,topic:31561”]
I’m not an LWJGL fanatic (I’ve never even used it!), and I’m certainly not trying to bash JOGL. I’m just looking for a solution to a problem. The point is that, in this particular case, I’m not using OpenGL for anything related to the UI. I’m using it for performing a long running computation, and that computation really doesn’t belong on the event thread.

Peter

Hm… I didn’t see anybody bashing anything, just answering questions. Oh well!

Yes, that’s all correct.

Great, thanks!

Just one more question: can this be scaled? That is, can I have several threads, each of which independently creates a pbuffer and renders to it? Or do I need to make sure that JOGL is only ever being used from one thread at a time, even if they’re rendering to unrelated contexts?

You can use OpenGL from multiple threads, but keep in mind that at least as of a few years ago, many drivers didn’t handle multithreaded OpenGL programs well. This is why JOGL uses a single thread by default. If you turn off JOGL’s built-in single threading support you can do whatever you want.