[SDL] Which platforms can do OpenGL outside the main thread? Will SDL support that? (Re: SDL OpenGL context and threads)
name.changed.by.editors at online.de
Fri Dec 31 08:33:53 PST 2010
Hi Michael and everyone else,
two years ago, I tried this using an early SDL 1.3 and Windows Vista, and it
worked. Windows does support this officially, AFAIK.
I asked for official SDL support, but got no response at all. So, this time I
will try to word my - no, our ;) - questions more clearly. They are:
1. Which platforms allow using OpenGL in a single thread that isn't the main thread?
2. Will SDL officially support using this capability where it exists?
Note that this is NOT about "multi-threaded rendering", where several threads
would use OpenGL in parallel. We just want one single OpenGL thread, but it
shall not be the main thread.
The motivation is that we are already forced (by so many systems) to do time
critical things like input/event handling in the main thread. I think it is
really a bad choice to have input handling and rendering in the same thread.
My ancient post is visible here:
I don't remember if I used SDL_GL_MakeCurrent or the Windows API wglMakeCurrent.
The documentation for SDL_GL_MakeCurrent does not specify how to deactivate the
context, so I guess I used wglMakeCurrent(NULL, NULL) directly.
Of course I was careful to only let one thread at a time touch the window and/or
its OpenGL context.
Note also that I did not use the OpenGL renderer built into SDL 1.3. I don't
know whether it could handle this use case. I called all GL functions directly.
On 31.12.2010 01:28, Michael Menegakis wrote:
> It's known that OpenGL drivers usually don't tolerate threading.
> However, does one have to deal with the main thread of SDL that
> brought up a GL context? If one spawns a thread and from then on only
> from there dispatches OpenGL commands will it be safe? Or does it have
> to be restricted to the main thread that brought up the SDL GL
> SDL mailing list
> SDL at lists.libsdl.org
More information about the SDL