SMPEG + OpenGL + Win32

I’ve noticed a difference in behaviour between Win32 and Linux where
smpeg + OpenGL is concerned. This is a topic that has come up before,
and I think it has something to do with multithreading.

I am using OpenGL to display (as a texture) the video image extracted by
smpeg. In the Linux version I use a callback: SMPEG_setdisplay(mpeg,
surface, NULL, update_surface). The function update_surface() invokes
the OpenGL calls to display the image. In Win32 the second time that
update_surface() is called a GL error is generated by the first GL
function encountered (e.g. glMatrixMode()). The error is #1282, invalid
operation. The fact that the first execution of update_surface() is
error-free is puzzling.

Can someone explain this? Is there a clever way to get around it? I
have a couple of not-so-clever ways. Using the callback, I can just
copy the pixels from smpeg’s surface to copy surface (with memcpy()) and
set a flag, then in my main loop display the copy when the flag is set.
This is a bit slow. Alternatively I can not use the callback, and just
display the surface at regular intervals.

Gib

Windows OpenGL contexts are thread-specific.

You could select the context into the thread with wglMakeCurrent–if
there’s a way to get access to the HGLRC–but it’s probably safer and
easier to just copy the data to a secondary buffer and set a flag, like
you described.

And if you do manage to get the context selected, you’re almost
certainly better off simply mutexing and updating the texture, and then
letting it get updated in a main rendering thread, than actually
rendering in multiple threads.On Sun, Feb 09, 2003 at 10:49:57AM +1300, Gib Bogle wrote:

I’ve noticed a difference in behaviour between Win32 and Linux where
smpeg + OpenGL is concerned. This is a topic that has come up before,
and I think it has something to do with multithreading.

I am using OpenGL to display (as a texture) the video image extracted by
smpeg. In the Linux version I use a callback: SMPEG_setdisplay(mpeg,
surface, NULL, update_surface). The function update_surface() invokes
the OpenGL calls to display the image. In Win32 the second time that
update_surface() is called a GL error is generated by the first GL
function encountered (e.g. glMatrixMode()). The error is #1282, invalid
operation. The fact that the first execution of update_surface() is
error-free is puzzling.

Can someone explain this? Is there a clever way to get around it? I
have a couple of not-so-clever ways. Using the callback, I can just
copy the pixels from smpeg’s surface to copy surface (with memcpy()) and
set a flag, then in my main loop display the copy when the flag is set.
This is a bit slow. Alternatively I can not use the callback, and just
display the surface at regular intervals.


Glenn Maynard