i’m developing a network monitor here at work, and its interface is made with opengl.

the application uses a FSM to manage itself, and while initializing it must show various steps, with onscreen messages.

opengl is being initialized correctly in a framework i wrote, and the FSM is invoked only when opengl is online (i can render things, set states and so on)

i start to invoke the FSM: it begins to startup by creating a thread where it initializes network connections, alarm management, in particular a text class (global) and various opengl states/params such as projection and modelview matrix, culling, depth testing…

the main FSM, just after the call to CreateThread() enters in a render cycle, where it waits from messages from the startup function. once a message is ready, it displays it via the text class.

the application starts, and begins to initialize, but seems like the startup thread don’t consider opengl initializations.

the opengl initializations and text class are working properly, because i tested them in a rendering loop, so the problem is not there.

among the other things, in the startup code i move the origin from the window center to the lower left corner with a gluOrtho2D() call, but the message still appear in the center.

are there some considerations when multithreading with opengl?

thanks for any help


[This message has been edited by dmy (edited 02-26-2000).]

ok, i found what the error was.
i post here for common knowledge.

opengl can work on multiple threads, but a thread must have exclusive access to the opengl state machine.

if opengl finds that its rendering context was not made current by the calling thread, it will simply do not consider calls.


I just read on the msdn that you must flush all drawing from different threads drawing to one window before you use swapbuffers for that window.

Maybe you weren’t using glFlush?

ummm… how do I make a thread the current thread ? I wanted to do the windows- message-handling in a many loop with low priority and OpenGL-rendering in a seperate thread with normal priority, but I can’t get OpenGL to render into the window. Is it just a single switch that I have forgotten to set?

For multithreaded and/or OOP code modules, it’s good idea to enter and exit with call to wglMakeCurrent() to enable/disable dispatching of GL commands.

i was away skiing for some time

yes, i thought about it. but a thread can be made current anytime… suppose a call to glBegin() in one thread, and a call to glBegin() in another thread… during the execution of the first glBegin() the second could be executed too… we have to implement some signaling/semaphoring, this way.

the processor takes care of making a thread current. you don’t have to care about that, and in fact i bet you don’t wish to do it all the time
the problem is that opengl knows wich thread owns the rendering context of a window, so we have to make opengl know that another thread need to do some rendering, and we tell it with a call to wglMakeCurrent()
in practice, if a thread owns a rendering context, opengl will render. anything else won’t work.
and again, it’s very important to keep instruction flux coherence, since opengl isn’t multi-pipelined.

no, it wasn’t this… before finding the real problem, i tried glFlush()/glFinish but the results didn’t changed.