I’m working with some 3rd party software that uses 2 contexts. On windows, it calls wglsharelists (or whatever that api is) to set up sharing for the 2nd context with the first.
Most of the opengl commands are run on a worker thread with the shared context. however, sometimes it does do opengl on a main thread using the original context.
In any case, to make this work, it can have a different opengl context current in each thread (main and rendering worker).
Since SDL ties the opengl context to an SDL_Window, this isn’t possible to do. It seems like I have to create a hidden window for the main thread and my main output window for the rendering worker.
Why does SDL tie the context to a window instead of the thread ?
This is definitely possible in SDL with just SDL_GL_MakeCurrent in each thread.
SDL?s OpenGL contexts are tied to windows, but they are also active on a thread-local basis just like with WGL (and CGL, GLX, EGL, EAGL, etc.)On Mar 25, 2014, at 4:04 PM, amol <amol.deshpande at gazillion.com> wrote:
I’m working with some 3rd party software that uses 2 contexts. On windows, it calls wglsharelists (or whatever that api is) to set up sharing for the 2nd context with the first.
Most of the opengl commands are run on a worker thread with the shared context. however, sometimes it does do opengl on a main thread using the original context.
In any case, to make this work, it can have a different opengl context current in each thread (main and rendering worker).
Since SDL ties the opengl context to an SDL_Window, this isn’t possible to do. It seems like I have to create a hidden window for the main thread and my main output window for the rendering worker.
Why does SDL tie the context to a window instead of the thread ?
It just kind of makes sense to arrange threads like sdl2 being that a single context cannot be current in multiple threads at the same time. I’m just talking about openGL. Maybe there is a use case where it does not? What is it you are doing?
R A Manard whisper8.com dranikist at gmail dot com
---- Alex Szpakowski wrote:=============
This is definitely possible in SDL with just SDL_GL_MakeCurrent in each thread.
SDL?s OpenGL contexts are tied to windows, but they are also active on a thread-local basis just like with WGL (and CGL, GLX, EGL, EAGL, etc.)
On Mar 25, 2014, at 4:04 PM, amol <amol.deshpande at gazillion.com> wrote:
I’m working with some 3rd party software that uses 2 contexts. On windows, it calls wglsharelists (or whatever that api is) to set up sharing for the 2nd context with the first.
Most of the opengl commands are run on a worker thread with the shared context. however, sometimes it does do opengl on a main thread using the original context.
In any case, to make this work, it can have a different opengl context current in each thread (main and rendering worker).
Since SDL ties the opengl context to an SDL_Window, this isn’t possible to do. It seems like I have to create a hidden window for the main thread and my main output window for the rendering worker.
Why does SDL tie the context to a window instead of the thread ?
Message-ID: <1395774262.m2f.42849 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
I’m working with some 3rd party software that uses 2 contexts. On windows, it
calls wglsharelists (or whatever that api is) to set up sharing for the 2nd context
with the first.
Most of the opengl commands are run on a worker thread with the shared
context. however, sometimes it does do opengl on a main thread using the
original context.
In any case, to make this work, it can have a different opengl context current in
each thread (main and rendering worker).
Since SDL ties the opengl context to an SDL_Window, this isn’t possible to do.
It seems like I have to create a hidden window for the main thread and my main
output window for the rendering worker.
Why does SDL tie the context to a window instead of the thread ?
thanks.
TO THE BEST OF MY KNOWLEDGE the only platforms that actually do tie
rendering to a particular thread are from Apple (iOS specifically,
though they may have changed that, since I last looked it up years
ago), all of the others will at least do some IPC (Windows, for
example, will do it via COM apartments).
Have you considered adding a function to create a "free floating"
context? As long as you limited the function to being used with a
specific version of SDL (a test that only has to be run once) you
should be able to get away with copying the actual definition(s) of
the render struct into the function’s implementation file.> Date: Tue, 25 Mar 2014 19:04:22 +0000
From: “amol” <amol.deshpande at gazillion.com>
To: sdl at lists.libsdl.org
Subject: [SDL] threads and opengl contexts and SDL on Linux