What is the correct way to clear OpenGL attributes set by
SDL_GL_SetAttributes?
Right now, I am manually resetting all OpenGL attributes to their default
values (as documented in the SDL wiki) before going through the context
creation process. This appears to be working, but I am not able to test
across all platforms.
Is there a better way to do this? If not, can I assume that the default
values are consistent across platforms (i.e. does SDL use the same rgb:332
default on Android/iOS?)
I need this for two reasons:
-
when creating multiple contexts, the attributes of the first context
implicitly affect the attributes of all subsequent contexts. In most cases,
this is not a problem, but in some cases it could cause unexpected failures.
-
I need more control on the fallback logic when a specific combination of
GL attributes is not supported. For instance, if a user requests 16x FSAA +
64bit accum + stereo, and context construction fails, then I “relax” these
parameters in order of importance (accum goes first, then FSAA is reduced,
then stereo, all the way down to hardware acceleration.) A failure is only
reported when no OpenGL capability is available whatsoever. This method of
"graceful degradation" is nice in that you can run the same app over a
remote desktop connection (no hardware acceleration) and still get
consistent results.
Cheers,
I think we should just add an SDL_GL_ResetAttributes, so that if we change the defaults in a future release or add new attributes, you don?t have to change your code.
Here?s a patch to do just that. If Sam or Ryan give a quick review, then I can slip it in to 2.0.2.
- J?rgen.On Jan 22, 2014, at 2:27 AM, Stefanos A. wrote:
What is the correct way to clear OpenGL attributes set by SDL_GL_SetAttributes?
Right now, I am manually resetting all OpenGL attributes to their default values (as documented in the SDL wiki) before going through the context creation process. This appears to be working, but I am not able to test across all platforms.
Is there a better way to do this? If not, can I assume that the default values are consistent across platforms (i.e. does SDL use the same rgb:332 default on Android/iOS?)
I need this for two reasons:
-
when creating multiple contexts, the attributes of the first context implicitly affect the attributes of all subsequent contexts. In most cases, this is not a problem, but in some cases it could cause unexpected failures.
-
I need more control on the fallback logic when a specific combination of GL attributes is not supported. For instance, if a user requests 16x FSAA + 64bit accum + stereo, and context construction fails, then I “relax” these parameters in order of importance (accum goes first, then FSAA is reduced, then stereo, all the way down to hardware acceleration.) A failure is only reported when no OpenGL capability is available whatsoever. This method of “graceful degradation” is nice in that you can run the same app over a remote desktop connection (no hardware acceleration) and still get consistent results.
Cheers,
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: resetattributes.patch
Type: application/octet-stream
Size: 5336 bytes
Desc: resetattributes.patch
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140127/4e6825d5/attachment.obj
I’m in favor!
JosephSent from my iPhone
On Jan 27, 2014, at 10:39, Jorgen Tjerno wrote:
I think we should just add an SDL_GL_ResetAttributes, so that if we change the defaults in a future release or add new attributes, you don?t have to change your code.
Here?s a patch to do just that. If Sam or Ryan give a quick review, then I can slip it in to 2.0.2.
On Jan 22, 2014, at 2:27 AM, Stefanos A. wrote:
What is the correct way to clear OpenGL attributes set by SDL_GL_SetAttributes?
Right now, I am manually resetting all OpenGL attributes to their default values (as documented in the SDL wiki) before going through the context creation process. This appears to be working, but I am not able to test across all platforms.
Is there a better way to do this? If not, can I assume that the default values are consistent across platforms (i.e. does SDL use the same rgb:332 default on Android/iOS?)
I need this for two reasons:
-
when creating multiple contexts, the attributes of the first context implicitly affect the attributes of all subsequent contexts. In most cases, this is not a problem, but in some cases it could cause unexpected failures.
-
I need more control on the fallback logic when a specific combination of GL attributes is not supported. For instance, if a user requests 16x FSAA + 64bit accum + stereo, and context construction fails, then I “relax” these parameters in order of importance (accum goes first, then FSAA is reduced, then stereo, all the way down to hardware acceleration.) A failure is only reported when no OpenGL capability is available whatsoever. This method of “graceful degradation” is nice in that you can run the same app over a remote desktop connection (no hardware acceleration) and still get consistent results.
Cheers,
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
<resetattributes.patch>
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Message-ID:
Content-Type: text/plain; charset=“utf-8”
I’m in favor!
Joseph
I think we should just add an SDL_GL_ResetAttributes, so that if we change
the defaults in a future release or add new attributes, you don?t have to
change your code.
Here?s a patch to do just that. If Sam or Ryan give a quick review, then I
can slip it in to 2.0.2.
I haven’t read the code, but I support the IDEA. Placing the
responsibility for something into the project that should have a
reliable idea of HOW to do it is always the correct choice.> Date: Mon, 27 Jan 2014 21:30:31 -0800
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] Correct way to clear GL attributes?
Sent from my iPhone
On Jan 27, 2014, at 10:39, Jorgen Tjerno wrote:
+1 from me!
2014-01-27 Jorgen Tjerno > I think we should just add an SDL_GL_ResetAttributes, so that if we
change the defaults in a future release or add new attributes, you don’t
have to change your code.
Here’s a patch to do just that. If Sam or Ryan give a quick review, then I
can slip it in to 2.0.2.
On Jan 22, 2014, at 2:27 AM, Stefanos A. wrote:
What is the correct way to clear OpenGL attributes set by
SDL_GL_SetAttributes?
Right now, I am manually resetting all OpenGL attributes to their
default values (as documented in the SDL wiki) before going through the
context creation process. This appears to be working, but I am not able to
test across all platforms.
Is there a better way to do this? If not, can I assume that the default
values are consistent across platforms (i.e. does SDL use the same rgb:332
default on Android/iOS?)
I need this for two reasons:
-
when creating multiple contexts, the attributes of the first context
implicitly affect the attributes of all subsequent contexts. In most cases,
this is not a problem, but in some cases it could cause unexpected failures.
-
I need more control on the fallback logic when a specific combination
of GL attributes is not supported. For instance, if a user requests 16x
FSAA + 64bit accum + stereo, and context construction fails, then I "relax"
these parameters in order of importance (accum goes first, then FSAA is
reduced, then stereo, all the way down to hardware acceleration.) A failure
is only reported when no OpenGL capability is available whatsoever. This
method of “graceful degradation” is nice in that you can run the same app
over a remote desktop connection (no hardware acceleration) and still get
consistent results.
Cheers,
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Gabriel.
Here?s a patch to do just that. If Sam or Ryan give a quick review, then
I can slip it in to 2.0.2.
First: revert the src/dynapi changes and run src/dynapi/gendynapi.pl
instead; new items need to be added to the end of the file to maintain
binary compatibility, and the script takes care of boring details like
that by parsing the public headers. This is a new thing and we didn’t
really document that anywhere yet.
Second: should we add a “reset this attribute” function, or a “reset all
attributes” function, or just a “tell me the default value of a specific
attribute” function? (I’m sort of leaning towards what you did to
blanket-reset the system without an SDL_Quit(), and a query for defaultd
for people that want to reset individual things…but I haven’t thought
this through yet).
–ryan.
2014-01-29 Ryan C. Gordon
Second: should we add a “reset this attribute” function, or a “reset all
attributes” function, or just a “tell me the default value of a specific
attribute” function? (I’m sort of leaning towards what you did to
blanket-reset the system without an SDL_Quit(), and a query for defaultd
for people that want to reset individual things…but I haven’t thought
this through yet).
There is little point in resetting individual settings, since the
application is already deriving its desired settings from somewhere (so
it can derive them again if necessary.) Plus, the user could always combine
SDL_GL_GetAttribute + SDL_GL_ResetAttributes + SDL_GL_SetAttribute to
save/restore individual settings.
Honestly, the best solution would be to add a new CreateContext function
with an explicit configuration argument:
typedef struct { int red_size; int green_size; /* … / } SDL_GLConfig;
void SDL_GL_InitConfig(SDL_GLConfig config);
SDL_GLContext* SDL_GL_CreateContextEx(SDL_Window* window, SDL_GLConfig*
config);
typedef struct { SDL_GLattr attribute; int value; } SDL_GLAttribute;
SDL_GLContext* SDL_GL_CreateContextAttribs(SDL_Window*
window, SDL_GLAttribute attribs[]);
This is slightly more work to implement than a blanket
SDL_GL_ResetAttributes(), but (a) it is cleaner and (b) it is atomic and
thread-safe. The current approach of spamming SDL_GL_SetAttribute() is
bound to blow up if two threads decide to create contexts at the same time.
This is certainly not for 2.0.2, but it would be nice to reduce reliance on
implicit state in general. OpenGL has also been evolving towards this
direction for the past several releases.
Honestly, the best solution would be to add a new CreateContext function with an explicit configuration argument:
typedef struct { int red_size; int green_size; /* … / } SDL_GLConfig;
void SDL_GL_InitConfig(SDL_GLConfig config);
SDL_GLContext* SDL_GL_CreateContextEx(SDL_Window* window, SDL_GLConfig* config);
typedef struct { SDL_GLattr attribute; int value; } SDL_GLAttribute;
SDL_GLContext* SDL_GL_CreateContextAttribs(SDL_Window* window, SDL_GLAttribute attribs[]);
This is slightly more work to implement than a blanket SDL_GL_ResetAttributes(), but (a) it is cleaner and (b) it is atomic and thread-safe. The current approach of spamming SDL_GL_SetAttribute() is bound to blow up if two threads decide to create contexts at the same time.
This is certainly not for 2.0.2, but it would be nice to reduce reliance on implicit state in general. OpenGL has also been evolving towards this direction for the past several releases.
I am in favor of the SDL_GL_CreateContextEx system (do we want to use that kind of naming? what about CreateContextWithConfig to explicitly call out what the difference is?), but I don?t think we should push that for 2.0.2. SDL_GL_ResetAttributes seems to solve the problem for most people, and it?s trivial to later re-implement ResetAttributes & CreateContext using a SDL_GL_InitConfig & SDL_GL_CreateContextWithConfig system.
As for the specific implementation, I?d like to see an approach where we pass a SDL_GLConfig* and sizeof(SDL_GLConfig), so that we can expand that struct in the future, while still having a nice way to access it. Passing pointers of key/value pairs is yucky.
Ryan: Thanks for the dynapi correction, after doing that, should I push it?
- J?rgen.On Jan 28, 2014, at 11:27 PM, Stefanos A. <stapostol at gmail.com<mailto:stapostol at gmail.com>> wrote: