[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Mon Sep 4 00:58:59 PDT 2006
On Monday 04 September 2006 04:13, Bob Pendleton wrote:
> David, I do this kind of stuff all the time. The SDL API *must* push
> all attributes, set what it needs, do the job, and restore the
> attribute and return.
The "opengl" renderer doesn't in the version I have, at least. It sets
the state up once, and assumes that no one is messing with it after
> This way the context stays the same from the
> end users point of view.
This has clearly never been the intention. Just like glSDL, the SDL
renderers are not intended to be used together with other code using
the same contexts.
> Someone is going to say that pushing and popping the context is to
> time consuming, I don't believe it.
Well, nothing is free, but all other alternatives seem more or less
nonsensical, or plain do not work, so...
The current initialization takes 9 calls or so. No big deal for
"normal" operation, but push, init, render, pop for every single
SDL_Render*() call...? (For comparison; each SDL_RenderCopy() call
generates around 15 OpenGL calls as it is.)
> The alternative is to put in a wedge layer to capture OpenGL context
> changes (a shadow stack) so that the context can be saved and
> restored out side of OpenGL. And I think that is an even worse idea
> that having a notification API. :-)
Yeah, seems like yet another way to "avoid" overhead by introducing
extra logic that costs more than it can ever save. :-D
> It is better to drop the whole idea than to put in the kind of
> notification API you were talking about. Us mere mortals don't want
> to deal with it and will get it wrong all the time. Consider how few
> people actually check return codes from C standard library
> calls. :-)
Good point. (It only affects people that hack SDL or use OpenGL and/or
Direct3D directly, and want to use SDL 2D libs over it, but that's
So, I guess it's either hardwiring state saving and restoring into the
SDL renderers, or possibly (if it actually matters) making it
optional by means of an "I want to share the OpenGL/Direct3D context
with the renderer" flag?
> If anything this is an argument for having a higher level SLD3D API
> that can take care of all of this stuff correctly no matter what the
> lower level API is. And, I know how popular that idea is! (Not at
And, this layer would still have to actually implement a solution
(explicit support for multiple "clients" per context?), which means
in the end, we'd probably have about the same amount of overhead,
only it's generated by more complex code.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
More information about the SDL