Another look at threads...

OpenGL Development JOGL Development
#1

I’ve written about issues I’m having with a fairly complex arrangement of multi-threading with Jogl. I want OpenGL calls on a separate thread from AWT, but I’m not planning to make calls continuously. I end up switching Jogl back and forth between AWT calling display on paints and my rendering thread calling display when it has been told it needs to render, and it causes problems.

I could simplify a lot by not having AWT call Jogl. What I’d like is for paint calls to allow me to tell my rendering thread to get going and call GLCanvas.display(). But GLCanvas is eating its paint calls (with noAutoRedrawMode set to true) without telling me about them. I get redraws as I rotate my image, but not when I expose the window (for example). I could find out about the paints by allowing the autoredraws, but then I’m back to switching Jogl back and forth and sharing it between two threads.

What I’d like is for GLCanvas to call some other method in my listener when it doesn’t call display because of no autoredraws. If it would tell me that its paint had been called, but not do the Jogl stuff, I could gig my rendering thread, and it could go call GLCanvas.display() again.

So GLEventListener could have an additional method, painted() or something, which the drawable calls instead of its own display call when not doing auto redraws. Of course, the whole autoredraw thing seems temporary at the moment.

Does that make sense?

I’d override GLCanvas if it weren’t final. I had trouble building Jogl, but I’m tempted to try again, so I could either just get rid of final, or add in something else to let me know that GLCanvas’s paint method was called. But I’d like to not have to replace all of the GLCanvas and GLContext stuff, and use things as standardly as possible.

Anybody else using Jogl in a multi-threaded fashion, without calling display() continuously? It seems to be in between the two ways the user’s guide discusses using Jogl.

andy

#2

As I mentioned on glenn’s thread, I decided I liked the idea of GLCanvas calling its parent’s paint() method if it doesn’t call its display() method because of the NoAutoRedrawMode. This has allowed me to really clean up my code, and it is a lot better.

I’ve submitted an enhancement request (issue #63). Don’t know if it will help anyone else, but it might help Glenn as well as me, because handling rendering on your own thread while still knowing that your canvas needs to be painted seems tricky in Jogl as currently done. (I wouldn’t mind being shown what I’m missing if there’s a way to do it without changing Jogl or making AWT notify me through GLEventListener.display().)

andy

#3

Ever feel the more you know, the dumber you feel? :slight_smile:

It didn’t occur to me until today that the more complicated way I was trying to handle a separate thread rendering Jogl was causing AWT to do the swap buffers, even if I just used the GLEventListener.display() method from AWT to tell my rendering thread to start and not making any OpenGL calls while in the AWT thread. I didn’t need that swap.

So that’s another reason why I’d like to see something like my enhancement request in issue #63. :slight_smile:

andy