[SDL] SDL 1.3 and rendering API state management

[David Olofson]

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 
that.


> 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 
bad enough.)

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
> all.)

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  --'