Display lists and threads

Do display lists need to be compiled in the same thread where they’re called?

I’m trying to attach a basic OpenGL window to an otherwise non-windowed program. So I don’t have a central event loop.

To get around this, I figured I’d spawn one thread corresponding to each window, and just have the event loop in there. This appears to work fine so long as the window is created within the thread.

However, due to an apparent bug in NVIDIA’s drivers which causes a crash whenever an OpenGL context is destroyed on XP64, I can’t just start a new thread whenever I’d like to change what’s being displayed. Instead, I have to update the data the thread is accessing.

Now, I could simply give the thread the object to draw. That works, but it’s inflexible. It won’t, for example, allow an easy way of superimposing one object’s image on another. The alternative seemed to be creating display lists outside the window thread, and then just calling them in the thread.

However, this doesn’t appear to work. Anyone have better ideas how I can approach this?

Another option would be getting function pointers in the mix, but that seems like overkill…

EDIT: It’s probably because I’m trying to compile the display list before creating the OGL context…
EDIT 2: Not the entire problem. Despite using conditions and signals to prevent the glGenLists call until the context is created, it still isn’t working.

Current OpenGL context is a per thread thing. Each thread has its own reference to context on which all GL calls issued by that thread operate. In your case the window thread called *glMakeCurrent() so that context is a current context for the window thread and GL calls work when called by that thread. The other thread does not have any current context so GL calls issued on that thread will fail (by specification behavior in such case is undefined).

One GL context can be current to at most one thread so you can not solve this by binding it to both threads. The second binding call will fail as long as the context is still bound somewhere else.

You can do something from the following:
[ul][]You can create additional context. Bind it to the second thread and use wglShareLists() to enable sharing of display list between both contexts. This path has the highest chance of hitting some bug in the driver.[]Or when you need to update the list you can unbind the context from the window thread, bind it to the worker thread, create the list and the bind the context back to the window thread for rendering.[*]Or the worker thread can create more complex program dependent structure describing scene to display and give that structure to the window thread. [/ul]