[…]
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.
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 --'On Monday 04 September 2006 04:13, Bob Pendleton wrote: