I am writing a program which paints to a GLCanvas from a Thread. However, while this thread paints it is possible that another Thread may also cause the GLCanvas to perform a repaint. It all seems to work all right, but I tried a
synchronized(glcanvas) {
canvas.repahin()
}
to try and ensure
sorry about that, I posted before finishing the question. :-[
What I was attempting to say was that I am repainting a GLCanvas from 2 seperate threads. I tried to use the synchronized(glcanvas) technique but this failed. My program has never crashed without using the synchronized keyword though which brings me to my question:
is there some inbuilt mechanism in JOGL to ensure mutual exclusion between 2 or more threads updating a common GLCanvas? Or is it frought with danger?
phew … I managed to finish the post this time ;D
Regards,
Sally
[quote]What I was attempting to say was that I am repainting a GLCanvas from 2 seperate threads. I tried to use the synchronized(glcanvas) technique but this failed. My program has never crashed without using the synchronized keyword though which brings me to my question:
[/quote]
Well, the repaint method doesn’t actually do any painting. It signals java that the next time through the event loop it should paint the Component. So if you call repaint multipule times before the Component is actually painted, it is collapsed down into one call to paint. Repaint is safe to call from any thread without any synchronization, and the Swing event loop will eventually tell the canvas to paint on the main Swing event loop thread.
[quote]is there some inbuilt mechanism in JOGL to ensure mutual exclusion between 2 or more threads updating a common GLCanvas? Or is it frought with danger?
[/quote]
I really don’t know if JOGL will pause a thread if another thread is currently in the display method. But if you are signaling that you would like to redraw using the repaint methods, then you don’t have to worry about this.
Oh good. That’s actually the answer I was hoping for. That’s quite a weight off my mind actually.
Thanks very much for that.
Regards,
Sally
On further thought, if I were calling GLDrawable.display()() method to update the canvas (instead of GLCanvas.repaint(), then I would expect the thread synchronization problem would crop up again (is this correct?).
I understand the repaint() method is normally used during annimation loops. But in my application where I read blocks of data (from a pipe or a file) and then try and display it on the GLCanvas - I would like to be in control of when the canvas updates rather than letting the event loop decide.
So do you think display() would be my best approach rather than repaint()?
I find my head seems to be spinning this evening with thoughts of threads, event loops, pixel formats etc whilst trying to get a solid design for my program … and I’m only doing 2d stuff. I’ll get there in the end 
Txs
Sally
Hi,
I may not understand well but if you use a customized version of FPSAnimator you can control when your display method should be called… (Maybe when resizing or bringing other window above yours makes other display but it should work…)
As is mentioned above, the AWT handles repaint() requests on one thread, so multiple threads calling repaint() are safe. JOGL also has enough internal synchronization (in theory) to handle multiple threads calling display() on the same GLDrawable. I say “in theory” because there have been many problems reported on various graphics cards probably related to synchronization and JOGL’s interaction with the AWT that we haven’t yet diagnosed.