Threading issue with JOGL (I think?)

[lhkbob]

I have a renderer done in jogl that uses the GLEventListener model for making contexts current on the AWT thread, etc.  I noticed that the duration of frames is wildly unstable, ranging from 50s to 1500s in simple scenes (generally in the 1000s, but then the slow frames made it jerky).  When profiling the threads, it showed that my main thread and the AWT thread would alternate blocking each other (doesn't seem good).

I then switched to using an active rendering approach to keep all rendering on my main thread.  Besides a substantial performance boost, the frame rates were very stable (compared to before).  Unfortunately, active rendering isn't as well supported, or so the docs warn about, so I'd like to use the GLEventListener model.

I don't have the multi-threading experience to track down what specifically causes the blocks.  Does anyone have advice for debugging this situation?

Thanks

[gouessej]

Hi!

I use GLEventListener but I explicitly call canvas.display() and it works reliably and fast. However, my frame rate is more stable since I use both JME 2.0 & JOGL. Maybe you should watch the source code of JME and mine too, I wrote a replacement of StandardGame because it didn't work fine with JOGL.

[DzzD]

and alternately you can check this one wich dont use GLEventListener :

http://www.java-gaming.org/topics/active-rendering-with-jogl/17661/view.html

Games published by our own members! Check 'em out!

[lhkbob]

Hi!

I use GLEventListener but I explicitly call canvas.display() and it works reliably and fast. However, my frame rate is more stable since I use both JME 2.0 & JOGL. Maybe you should watch the source code of JME and mine too, I wrote a replacement of StandardGame because it didn't work fine with JOGL.

I've noticed this, and that's why it's troubling to me.  In my old applications I had stable rates with JOGL too.  I just don't what I did that changed things, and I was hoping someone could point out a general attack plan to track down the problem.

and alternately you can check this one wich dont use GLEventListener :

http://www.java-gaming.org/topics/active-rendering-with-jogl/17661/view.html

I use active rendering very much like this.  Unfortunately I've discovered artifacts when using it on Mac OS X.  When frame rates are low (< 20), other windows can cause artifacts in the java frame (it resemebles double-buffering conflicts).

[DzzD]

I use active rendering very much like this.  Unfortunately I've discovered artifacts when using it on Mac OS X.  When frame rates are low (< 20), other windows can cause artifacts in the java frame (it resemebles double-buffering conflicts).

thanks to share your experience, I did not know there was issue on Mac, di you try to found a solution or reasons of those artefacts ?

[lhkbob]

I haven't found a solution yet, but I'll look into it if I can't get the AWT thread to perform better.

Here are some graphs of the fps of a test scene, each sample is the average fps of 10 consecutive frames.  The data was taken after a reasonable start-up time.  The first is the fps when using single-threaded active rendering on the main thread, the second is using the GLEventListener on the AWT thread.

[lhkbob]

Here is an example of what the active rendering glitch looks like on Mac.

[DzzD]

I already see such but on window with Applet, it appear as it become a dead zone never more rendered. probably a solution can be found but dont have any idea right now...

EDIT :
maybe validate/invalidate/repaint the canvas ?

[lhkbob]

I've set the canvas and frame to ignore repaints.  I tried using a BufferedStrategy (that failed miserably).  I'm at a complete loss as to what causes it (it doesn't seem to be in response to paint calls).  Also, for some reason it only seems to happen now when I use display lists, and then the problem only starts once another window becomes focused.  AGGHHGHG!!!!

[gouessej]

I spoke too fast... I still have some very short slowdowns  Please Kenneth tell us when we could benefit of a release version of JOGL 2.0 with a native window without AWT.