hi all!
I found one problem, which is only on Windows[VC++ 6.0 SE]. (I just tried to
look for it only on the Linux and Windows).
The SDL_AddTimer function calls callback function in the new thread (I think).
On the Linux from this callback function I can use OpenGL funcions. Such like
glClear, … On the Windows I can’t call OpenGL functions, so only the call to
SDL_GL_SwapBuffers(); from my callback function is executed 
If anybody knows, how to fix it, please answer me.
regards,
snucker
As far as I know, Windows only allows an OpenGL context to be selected
into one thread at a time. There is probably no fix; I’m guessing that
the drivers arn’t threadsafe.
This is a problem to me, because I run a movie decoder in a separate
thread. I send frames to a texture, but since the decoder is separate I
have to copy it to a holding buffer to be uploaded by the main thread;
for high-resolution movies, this is a significant performance hit.
Conveniently for MS, Direct3D doesn’t have this problem. Ugh.
Now that I think about it again, I might be able to sync this: have the
decoder thread signal the main thread to stop and let go of the context
so the decoder thread can upload the texture. Now I just need to see if
there’s a way I can get access to the rendering context with SDL.
(That probably doesn’t help you at all, though.)On Sun, Apr 20, 2003 at 12:29:25AM +0400, snucker wrote:
The SDL_AddTimer function calls callback function in the new thread (I
think). On the Linux from this callback function I can use OpenGL funcions.
Such like glClear, … On the Windows I can’t call OpenGL functions, so
only the call to SDL_GL_SwapBuffers(); from my callback function is
executed
–
Glenn Maynard
Glenn Maynard wrote:> On Sun, Apr 20, 2003 at 12:29:25AM +0400, snucker wrote:
The SDL_AddTimer function calls callback function in the new thread (I
think). On the Linux from this callback function I can use OpenGL funcions.
Such like glClear, … On the Windows I can’t call OpenGL functions, so
only the call to SDL_GL_SwapBuffers(); from my callback function is
executedAs far as I know, Windows only allows an OpenGL context to be selected
into one thread at a time. There is probably no fix; I’m guessing that
the drivers arn’t threadsafe.This is a problem to me, because I run a movie decoder in a separate
thread. I send frames to a texture, but since the decoder is separate I
have to copy it to a holding buffer to be uploaded by the main thread;
for high-resolution movies, this is a significant performance hit.
Conveniently for MS, Direct3D doesn’t have this problem. Ugh.Now that I think about it again, I might be able to sync this: have the
decoder thread signal the main thread to stop and let go of the context
so the decoder thread can upload the texture. Now I just need to see if
there’s a way I can get access to the rendering context with SDL.(That probably doesn’t help you at all, though.)
can’t `SDL_GL_GetProcAddress(const char *)’ from the additional thread do this?
Do what? That looks up function pointers, which isn’t relevant here.On Sun, Apr 20, 2003 at 09:39:39AM +0400, snucker wrote:
can’t `SDL_GL_GetProcAddress(const char *)’ from the additional thread do
this?
–
Glenn Maynard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Sunday 20 April 2003 00:09, Glenn Maynard wrote:
On Sun, Apr 20, 2003 at 12:29:25AM +0400, snucker wrote:
The SDL_AddTimer function calls callback function in the new thread (I
think). On the Linux from this callback function I can use OpenGL
funcions. Such like glClear, … On the Windows I can’t call OpenGL
functions, so only the call to SDL_GL_SwapBuffers(); from my callback
function is executedAs far as I know, Windows only allows an OpenGL context to be selected
into one thread at a time. There is probably no fix; I’m guessing that
the drivers arn’t threadsafe.This is a problem to me, because I run a movie decoder in a separate
thread. I send frames to a texture, but since the decoder is separate I
have to copy it to a holding buffer to be uploaded by the main thread;
for high-resolution movies, this is a significant performance hit.
Conveniently for MS, Direct3D doesn’t have this problem. Ugh.Now that I think about it again, I might be able to sync this: have the
decoder thread signal the main thread to stop and let go of the context
so the decoder thread can upload the texture. Now I just need to see if
there’s a way I can get access to the rendering context with SDL.(That probably doesn’t help you at all, though.)
Depending on how the decoder works, couldn’t you use some double (or
triple/quad/whatever)-buffering scheme to avoid the unnecessary copying?
I.e. allocate three buffers for frames. Decode into the buffers and set a
flag when a buffer is ready for upload. The main thread then sets another
flag once the buffer has been uploaded and is ready to be used again.
This is probably cheaper than switching the context around all the time.
cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+omo9sxPozBga0lwRAj1wAKCR4fbJjCf7O4anBBrHlhJ9Sfu8ngCfbZ+Y
SSrKSA0CEvd+SEMhThEZNDA=
=72tD
-----END PGP SIGNATURE-----
Glenn Maynard wrote:> On Sun, Apr 20, 2003 at 09:39:39AM +0400, snucker wrote:
can’t `SDL_GL_GetProcAddress(const char *)’ from the additional thread do
this?Do what? That looks up function pointers, which isn’t relevant here.
But we can call `SDL_GL_LoadLibrary(const char *)’ from the additional thread
before. It must give function pointers, doesn’t it?
That was my first thought, but we’re using DirectShow and I have no idea
how or if it can do that.
One thing I suspect is that it’s actually only updating deltas in the buffer
that it’s returning the data in, so it doesn’t have to do an extra copy
internally. In that case, it’d be either impossible to double-buffer or
it’d cost as much as it’d save, trading copying the frame myself for having
DShow do it for me.On Sun, Apr 20, 2003 at 11:37:00AM +0200, Nicolai Haehnle wrote:
Depending on how the decoder works, couldn’t you use some double (or
triple/quad/whatever)-buffering scheme to avoid the unnecessary copying?
I.e. allocate three buffers for frames. Decode into the buffers and set a
flag when a buffer is ready for upload. The main thread then sets another
flag once the buffer has been uploaded and is ready to be used again.
–
Glenn Maynard
Possibly, but you can’t use them, since the thread doesn’t have an
OpenGL context selected into it.On Sun, Apr 20, 2003 at 11:35:10PM +0400, snucker wrote:
But we can call `SDL_GL_LoadLibrary(const char *)’ from the additional
thread before. It must give function pointers, doesn’t it?
–
Glenn Maynard