Threads and JOGL

OpenGL Development JOGL Development
#1

Hi all,

I’m trying to make an app, where a thread can perform various tasks when no rendering occurs. When render occurs (i.e display() is called), a flag in the thread is set to true, and the thread waits until the flag is set to false. That flag is set true at the begining of the display(), and is set to false when display ends. The thread’s run can call an update method, which calls display(), but only if display isn’t running at that time.

The problem is that is some occasions I get the “Error making context current” GLException message, accompanied by a number: -1073282975, and the whole thing freezes… Does anyone know what does this number mean? What would be an efficient way to use threads that can cause repaint whithout getting the above exception?

TIA
N

#2

I came across the 2004 JavaOne presentation for jogl, and in slide 20 the following guidelines were provided for multithreading:

[i]Multithreading

AWT events like mouse and keyboard events
are delivered on AWT event queue thread
• Not allowed / possible to make OpenGL calls
directly inside these listeners
─ Though you can schedule or force a redraw
• Instead, pass information between these
threads and any animation threads via
member data
─ Use appropriate synchronization
─ Read data exactly once in your display() method
[/i]

So, the key to the problem must be to avoid accidental GL calls by two different threads. I thought I was blocking such cases in my application, but when I avoid using mutiple threads, there is no problem… I suppose I must check it thoroughly.

#3

Are you using the latest JOGL build from the “Documents & Files” section of the JOGL web page?

Your scheduling mechanism sounds a little complicated. Why not just have an animation loop which does physics computation, etc. and then calls display() to redraw your component?

#4

Yes, I’m using the last version, but I get the same problem using older versions too.

What I’m trying to do is not a scheduling mechanism. I’m trying to load data from disk when no rendering occurs (or when the camera’s position and orientation doesn’t change), so as to keep a high frame rate that is not stalled by loading data. So, data loading is done in a thread, and the thread runs only when no rendering occurs. When some data are loaded, the view must be updated, so my thread must somehow cause a rendering to happen. That exact point seems to cause the whole problem.

Using an Animator might help with the refreshing, but it would leave minimum render idle time to use for loading data (not to mention that the CPU load is significantly higher).

#5

Do the JOGL demos produce the same error code? What graphics card do you have? Are you using the latest version of your vendor’s drivers? What is the output of “java demos.printext.PrintExt”?

I think you’d be better off just creating a background thread to do your loading work and lowering the priority of that thread. The operating system should handle scheduling of your work. You can provide hints to your background thread about when to run but I would recommend doing this only at a coarse-grained level.

#6

I’ve tried yield() in the background thread and so far this seems to work, but I’m not certain it’s 100% correct. I’ll also tried lowering the priority of the thread. I 'm not sure I understand what you exactly mean when you say that “The operating system should handle scheduling of your work”. My thread should somehow cause display to run() because some data have been loaded…I don’t think its a subject of arranging rendering calls. I’m trying to find the right way to provide hints to my background thread, as you suggested so as not to interfere with the rendering process. What exactly do you mean by saying that I must do this at a coarse-grained level?

My card is a Mobility Radeon 9000 on an Acer Travelmate, so it uses custom vendor drivers. Its drivers have not been updated since 2003 and some of the jogl demos (render to texture example and others) are not running. I’ll try to see what happens when using threads in the jogl demos, and check out the result of PrintExt.

#7

I believe it will be difficult to break your work up into very small chunks which can be scheduled and descheduled on demand on your background thread. While you may be able to tell your background thread when the rendering loop is idle, a repaint request can come in at any time, and it will be very difficult to try to immediately suspend the background work before beginning your rendering operation. You would probably be better off beginning your background work when the display goes idle and have it stop “soon after” rendering resumes.

#8

I’ve done some debugging, and the results “agree” with your suggestions. Because of scheduled rendering calls, I can’t immediately “block” my thread, when render occurs.

Thank you for your time and suggestions!