# SDL 1.3 and rendering API state management

**URL:** <https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815>\
**Category:** SDL Development\
**Created:** [September 3, 2006, 8:21am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815 "2006-09-03T08:21:56Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 8:21am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/1 "2006-09-03T08:21:56Z")

</div>

I realized there is another problem as well: Just like glSDL, SDL 1.3  
(at least the OpenGL renderer) relies on some parts of the API state  
to remain unchanged between calls. This means an application or  
add-on library cannot safely change anything, nor can it rely on the  
state to be unaffected by SDL rendering calls.

For example, in GL\_RenderCopy():  
[…]  
if (blendMode != data-\>blendMode) {  
switch (blendMode) {  
[…]  
}  
data-\>blendMode = blendMode;  
[…]  
…and a similar construct for scaleMode.

A simple solution would be some kind of mutual notification interface,  
so that SDL renderers can tell the application when they’ve messed  
with the API state, and vice versa.

To make it more effective, one might use a bit mask instead of just a  
single “something changed” flag. One bit for view setup, one for  
blending, one for scaling etc. Without this, both SDL and  
applications/add-on libs will have to do a full state restore  
whenever the other side says it touched “something”. The bit mask can  
still be tested like a single boolean if desired, of course.

Also, there doesn’t seem to be a way to update any dirty areas of a  
texture without performing a dummy blit. A specific call to do only  
that part (now hardwired into \*\_RenderCopy() implementations) would  
be handy.

Another way of dealing with these kind of issues would be to make the  
SDL renderer interface public, so that applications and add-on libs  
can plug entire renderers into SDL. That way, one could wire _all_  
rendering, including the SDL calls, to the same renderer, instead of  
trying to get two separate renderers to cooperate. Of course, this  
means quite a bit of code duplication, but it’s probably safer…

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
’-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --’

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [September 3, 2006, 9:12am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/2 "2006-09-03T09:12:23Z")

</div>

> A simple solution would be some kind of mutual notification interface,  
> so that SDL renderers can tell the application when they’ve messed  
> with the API state, and vice versa.

Alternately, you can use glPushAttrib().

I don’t think SDL should make _any_ promises about what it will or won’t  
touch in the GL stack if you are only using SDL’s 2D facilities. Nor do  
I think that any add-on library should be changing GL state between  
calls. If you want to draw something, set your state, push some  
polygons, and set the state back. Otherwise, you’re talking about  
locking down a fairly complicated set of promises (or specifying a  
fairly complicated set of notification APIs).

–ryan.

---

<div class="post-metadata">

**Author:** ![Torsten\_Giebl](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/torsten_giebl/32/2804_2.png) [@Torsten\_Giebl](https://discourse.libsdl.org/u/Torsten_Giebl)\
**Post date:** [September 3, 2006, 9:30am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/3 "2006-09-03T09:30:29Z")

</div>

Hello !

> I realized there is another problem as well: Just like glSDL, SDL 1.3  
> (at least the OpenGL renderer) relies on some parts of the API state  
> to remain unchanged between calls. This means an application or add-on  
> library cannot safely change anything, nor can it rely on the state to be  
> unaffected by SDL rendering calls.

Is it not possible in OpenGL to save these states,  
then modify them, do all the blittings, restore them ?

CU

---

<div class="post-metadata">

**Author:** ![Torsten\_Giebl](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/torsten_giebl/32/2804_2.png) [@Torsten\_Giebl](https://discourse.libsdl.org/u/Torsten_Giebl)\
**Post date:** [September 3, 2006, 9:34am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/4 "2006-09-03T09:34:11Z")

</div>

Hello !

> Is it not possible in OpenGL to save these states,  
> then modify them, do all the blittings, restore them ?

What about Direct3D ?

CU

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 9:47am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/5 "2006-09-03T09:47:10Z")

</div>

> > A simple solution would be some kind of mutual notification  
> > interface, so that SDL renderers can tell the application when  
> > they’ve messed with the API state, and vice versa.
> 
> Alternately, you can use glPushAttrib().

Well, the hard part is figuring out when to do this… I can’t see any  
sensible way to automate it, so for all practical matters, it’s  
“manual control” from the application side. Error prone and hard to  
debug - especially if the offending code is not your own, but inside  
various add-on libs that you’re trying to use together.

> I don’t think SDL should make _any_ promises about what it will or  
> won’t touch in the GL stack if you are only using SDL’s 2D  
> facilities. Nor do  
> I think that any add-on library should be changing GL state between  
> calls. If you want to draw something, set your state, push some  
> polygons, and set the state back.

This is (sort of) fine if you’re using OpenGL (or Direct3D) directly  
in the application code, but what if you’re “just” trying to use an  
add-on library that’s supposed to add some extra rendering calls?

To a user not aware of the inner workings of these things, it probably  
seems very strange that various add-on libs all using SDL and  
supporting the same rendering APIs still just won’t work together  
without various mysterious rituals.

I think the current situation with SDL 1.2, OpenGL, glSDL, various GUI  
toolkits etc, is hindering code reuse and making SDL tricky to use -  
and there isn’t even a good technical reson for these problems in the  
first place! They are just side effects of SDL 1.2 not being designed  
to deal with these issues.

> Otherwise, you’re talking about locking down a fairly complicated  
> set of promises (or specifying a fairly complicated set of  
> notification APIs).

That’s exactly why I’m suggesting either a notification interface, or  
simply having the add-on libraries plugging in new SDL renderers,  
that implement the standard SDL 2D API in suitable ways. Both  
solutions relieve both SDL and the add-on libs from the burden of  
making any promises; the first by allowing both sides to say when  
they’ve changed things, and the second by simply turning add-on  
rendering libs into plug-in SDL renderers.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 9:50am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/6 "2006-09-03T09:50:25Z")

</div>

> Hello !
> 
> > I realized there is another problem as well: Just like glSDL, SDL  
> > 1.3  
> > (at least the OpenGL renderer) relies on some parts of the API  
> > state  
> > to remain unchanged between calls. This means an application or  
> > add-on  
> > library cannot safely change anything, nor can it rely on the  
> > state to be  
> > unaffected by SDL rendering calls.
> 
> Is it not possible in OpenGL to save these states,  
> then modify them, do all the blittings, restore them ?

Yeah, but it’s not something you want to do for every rendered  
primitive…

Indeed, the application can explicitly say “now I’m going to use  
Advanced2D for a while”, and then “now I’m going to make some SDL  
rendering calls” - but this is error prone and results in strange and  
hard to find bugs if/when mistakes are made. Even harder to get right  
if you’re using for example a rendering lib and a GUI toolkit lib  
together, rather than making the rendering calls directly.

With some kind of mutual notification interface, this could be done  
automatically by SDL and/or the add-on lib - that is, actual work is  
done only when switching between SDL rendering and add-on library  
calls. (Of course, that makes it a bad idea to mix wildly - but  
that’s not really what I’m trying to support. I’m just trying to  
minimize the risk of SDL 1.3/2.0 add-on libs mysteriously breaking  
when used together.)

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 11:30, Torsten Giebl wrote:

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 9:53am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/7 "2006-09-03T09:53:17Z")

</div>

Same deal, I guess. Not that up to date with Direct3D…

Anyway, if you can’t push and pop, there’s always the option of all  
parties reinitializing the state the way they want it, when told that  
some one else changed it.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 11:34, Torsten Giebl wrote:

> Hello !
> 
> > Is it not possible in OpenGL to save these states,  
> > then modify them, do all the blittings, restore them ?
> 
> What about Direct3D ?

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 11:40am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/8 "2006-09-03T11:40:11Z")

</div>

[…]

> I don’t think SDL should make _any_ promises about what it will or  
> won’t touch in the GL stack if you are only using SDL’s 2D  
> facilities. Nor do I think that any add-on library should be  
> changing GL state between calls. If you want to draw something, set  
> your state, push some polygons, and set the state back. Otherwise,  
> you’re talking about locking down a fairly complicated set of  
> promises (or specifying a fairly complicated set of notification  
> APIs).

BTW, in this particular case (SDL\_Advanced2D), I think it’s somewhat  
acceptable if the library has to track SDL revisions rather closely.  
(An SDL renderer versioning API, maybe?)

After all, this started out as a discussion as to whether this stuff  
belongs in SDL, or in an add-on library. In a less minimalistic and  
more application specific library, the obvious solution would have  
been to build this into SDL, but - provided these state sharing  
issues can be dealt with nicely - an add-on/plugin approach is more  
flexible and keeps the SDL core smaller, cleaner and simpler.

So, some possible solutions:

```
1. Make the SDL renderer interface public, so add-on
   libs can plug in their own renderers.
	+ Rock solid and efficient - all rendering
	  calls are made from a single place.
	+ Allows renderers for *anything* to be
	  plugged in at run time.
	- Existing SDL renderer features have to
	  be duplicated in external renderers.

2. Add a mutual state change notification interface
   for SDL renderers and applications/add-on libs.
	+ Easy to implement (?)
	- Somewhat error prone. (How do you make
	  sure you're actually "sending" all required
	  notifications?)

3. Build Advanced2D into the SDL core.
	+ All in one place - no state sharing issues.
	+ 2D and Advanced2D code is pretty much
	  guaranteed to work together.
	+ Less risk of different competing solutions
	  that won't cooperate.
	- Bloats the SDL core library.
	- Makes other targets much more different
	  from OpenGL and Direct3D. (Stuff beyond
	  the current API doesn't really lend itself
	  to real time software rendering.)
	- No good if you want something else than
	  Advanced2D.

4. Have applications and add-on libs "manually" manage
   state as needed.
	- Expensive (if you save and restore
	  "everything" all the time), and/or error
	  prone and hard to debug.
	- Hard to make add-on libs work together.

5. Simply don't support mixed SDL/Advanced2D rendering.
   GUI toolkits and the like must be able to render
   using any add-on libs they should be able to
   cooperate with.
	+ Very easy.
	- Doesn't help to make code reuse easier.

```

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:

---

<div class="post-metadata">

**Author:** ![Antonio\_Musumeci](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@Antonio\_Musumeci](https://discourse.libsdl.org/u/Antonio_Musumeci)\
**Post date:** [September 3, 2006, 1:57pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/9 "2006-09-03T13:57:53Z")

</div>

I’m in favor of 1. I asked about this a while back. I see no good reason  
to require the SDL drivers to be compile time elements only. The  
flexibility is in the core for the most part already… just make it  
public. SDL already provides runtime linking wrappers. If the interfaces  
for all major components are made public… driver development would be  
easier too. Let the drivers/renderers add to some database that they  
exist and capabilities so users can easily query for the information. I  
know we argued about a query system before… but I think in the  
least… everything which is easily known at compile time (platform,any  
base drivers) and at runtime (arch,SIMD,supported audio/image formats).  
So if SDL\_Image doesn’t support format X… I can create my own X plugin  
and provide it with my app without needing to provide all of SDL\_Image.  
Then you can keep core SDL as just a flexible plugin interface for  
video/audio/input/etc.

David Olofson wrote:\> On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:

> […]
> 
> > I don’t think SDL should make _any_ promises about what it will or  
> > won’t touch in the GL stack if you are only using SDL’s 2D  
> > facilities. Nor do I think that any add-on library should be  
> > changing GL state between calls. If you want to draw something, set  
> > your state, push some polygons, and set the state back. Otherwise,  
> > you’re talking about locking down a fairly complicated set of  
> > promises (or specifying a fairly complicated set of notification  
> > APIs).
> 
> BTW, in this particular case (SDL\_Advanced2D), I think it’s somewhat  
> acceptable if the library has to track SDL revisions rather closely.  
> (An SDL renderer versioning API, maybe?)
> 
> After all, this started out as a discussion as to whether this stuff  
> belongs in SDL, or in an add-on library. In a less minimalistic and  
> more application specific library, the obvious solution would have  
> been to build this into SDL, but - provided these state sharing  
> issues can be dealt with nicely - an add-on/plugin approach is more  
> flexible and keeps the SDL core smaller, cleaner and simpler.
> 
> So, some possible solutions:
> 
> 1. Make the SDL renderer interface public, so add-on  
> libs can plug in their own renderers.
> 
> 2. Add a mutual state change notification interface  
> for SDL renderers and applications/add-on libs.
> 
> 3. Build Advanced2D into the SDL core.
> 
> 4. Have applications and add-on libs “manually” manage  
> state as needed.
> 
> 5. Simply don’t support mixed SDL/Advanced2D rendering.  
> GUI toolkits and the like must be able to render  
> using any add-on libs they should be able to  
> cooperate with.
> 
> //David Olofson - Programmer, Composer, Open Source Advocate
> 
> .------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
> | [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
> | [http://audiality.org](http://audiality.org) - Music/audio engine |  
> | [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
> ‘-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --’
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

---

<div class="post-metadata">

**Author:** ![Torsten\_Giebl](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/torsten_giebl/32/2804_2.png) [@Torsten\_Giebl](https://discourse.libsdl.org/u/Torsten_Giebl)\
**Post date:** [September 3, 2006, 2:05pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/10 "2006-09-03T14:05:37Z")

</div>

Hello !

If this could be a perf. problem  
pushing/poping the state for every vertice  
it should be no problem to have two calls  
like SDL\_2D\_Begin () / SDL\_2D\_End () surrounding all  
your blitting blocks.

CU

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 4:36pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/11 "2006-09-03T16:36:29Z")

</div>

> I’m in favor of 1.

Yeah, I’m leaning towards that one too.

Doesn’t feel quite right to bypass everything, including display  
setup, but then again, if the renderer “plugin” API is made public,  
you can basically just rip that code from SDL. Not exactly megabytes  
of code anyway! 🙂

The advantages seem to be major ones, though - and it solves the SDL  
2D vs external renderer “extension” conflicts in a clean and  
potentially very efficient way. (No extra cost for mixing SDL 2D and  
“extended” calls, as both are wired to the same renderer.)

[…]

> Let the drivers/renderers add to some database that they exist and  
> capabilities so users can easily query for the information.

Interfaces for that are already in place and nice looking, AFAICT -  
it’s just that the renderer side of it is private.

> I know we argued about a query system before… but I think in the  
> least… everything which is easily known at compile time  
> (platform,any base drivers) and at runtime (arch,SIMD,supported  
> audio/image formats).

Yeah, that might be handy. (Not directly related to renderers,  
though.)

> So if SDL\_Image doesn’t support format X… I can create my own X  
> plugin and provide it with my app without needing to provide all of  
> SDL\_Image.

Yeah… Rename SDL\_LoadBMP() as SDL\_LoadSurface() (or something), and  
convert SDL\_image into a plugin that adds support for more file  
formats?

> Then you can keep core SDL as just a flexible plugin interface for  
> video/audio/input/etc.

Yeah, I like the idea. Makes it a lot easier to make various add-on  
libs work together without actually modifying them to do so. Most of  
the interfaces are more or less polymorphic anyway, so why not make  
full use of it?

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 15:57, Antonio SJ Musumeci wrote:

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 4:37pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/12 "2006-09-03T16:37:21Z")

</div>

That works, but that’s the sort of explicit manual control I’m trying  
to avoid. To some developer just trying to get some extra rendering  
operations and a GUI toolkit or something in the same application, it  
just looks like it’s not really meant to be done.

Why not do it properly while we’re at it? Unless there is a clean way  
of getting “normal” SDL code to play along with code using OpenGL or  
Direct3D directly, we’re not really improving the situation much  
compared to SDL 1.2.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 16:05, Torsten Giebl wrote:

> Hello !
> 
> If this could be a perf. problem  
> pushing/poping the state for every vertice  
> it should be no problem to have two calls  
> like SDL\_2D\_Begin () / SDL\_2D\_End () surrounding all  
> your blitting blocks.

---

<div class="post-metadata">

**Author:** ![Torsten\_Giebl](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/torsten_giebl/32/2804_2.png) [@Torsten\_Giebl](https://discourse.libsdl.org/u/Torsten_Giebl)\
**Post date:** [September 3, 2006, 5:17pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/13 "2006-09-03T17:17:58Z")

</div>

Hello !

> Doesn’t feel quite right to bypass everything, including display  
> setup, but then again, if the renderer “plugin” API is made public, you can  
> basically just rip that code from SDL. Not exactly megabytes of code  
> anyway! 🙂
> 
> The advantages seem to be major ones, though - and it solves the SDL  
> 2D vs external renderer “extension” conflicts in a clean and  
> potentially very efficient way. (No extra cost for mixing SDL 2D and  
> “extended” calls, as both are wired to the same renderer.)

How does this work ?

The coder hast copy&paste the renderers from 1.3 ? Always ?

CU

---

<div class="post-metadata">

**Author:** ![Torsten\_Giebl](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/torsten_giebl/32/2804_2.png) [@Torsten\_Giebl](https://discourse.libsdl.org/u/Torsten_Giebl)\
**Post date:** [September 3, 2006, 5:34pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/14 "2006-09-03T17:34:26Z")

</div>

Hello !

> > I’m in favor of 1.
> 
> Yeah, I’m leaning towards that one too.
> 
> Doesn’t feel quite right to bypass everything, including display  
> setup, but then again, if the renderer “plugin” API is made public, you can  
> basically just rip that code from SDL. Not exactly megabytes of code  
> anyway! 🙂
> 
> The advantages seem to be major ones, though - and it solves the SDL  
> 2D vs external renderer “extension” conflicts in a clean and  
> potentially very efficient way. (No extra cost for mixing SDL 2D and  
> “extended” calls, as both are wired to the same renderer.)

I can image a plugin system like in XMMS, GIMP or other apps.  
But it is hard for me how such a system could be used in SDL.

How is the state problem solved here ?

I look at how SDL inits the states  
and copy these settings in my code ?

What about people that do not use 3D ?

What about bugfixes in the SDL code ?

CU

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 5:36pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/15 "2006-09-03T17:36:33Z")

</div>

No, only?if you’re going to do “backend stuff”. Normal applications  
and other code that uses the SDL API (or plugin extensions to it) are  
not affected by this.

When using the SDL API, you aren’t really supposed to be using OpenGL,  
Direct3D or whatever the SDL rendererer is using, directly. You’re  
supposed to use the SDL API.

Now, if you want to extend SDL - add more rendering operations, add  
support for another target (QuickDraw, Pixomatic, some odd console  
chipset, …) - you’re in backend land. You’re effectively messing  
with the internal operation of SDL as a side effect of (ab)using the  
same target context that the SDL renderer is using.

It’s really not very different from the situation with SDL 1.2 and  
OpenGL: If you want to do OpenGL rendering, you have to do all of it  
yourself. (Well, except for setting up the display.) As you set up  
the display for OpenGL rendering, the SDL 2D API is rendered unusable  
on the display surface. To bring it back to life, you need to slap  
glSDL/wrapper in between the application and SDL.

What glSDL/wrapper does is essentially what an SDL 1.3 renderer does:  
It implements the SDL 2D rendering API over OpenGL, so that the  
application can still use the SDL 2D calls. The only difference is  
that glSDL does it compile time be means of a bunch of messy  
redefinitions, whereas an SDL 1.3 renderer fills in a struct with a  
bunch of low level functions at run time.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 19:17, Torsten Giebl wrote:

> Hello !
> 
> > Doesn’t feel quite right to bypass everything, including display  
> > setup, but then again, if the renderer “plugin” API is made  
> > public, you can basically just rip that code from SDL. Not exactly  
> > megabytes of code anyway! 🙂
> > 
> > The advantages seem to be major ones, though - and it solves the  
> > SDL 2D vs external renderer “extension” conflicts in a clean and  
> > potentially very efficient way. (No extra cost for mixing SDL 2D  
> > and “extended” calls, as both are wired to the same renderer.)
> 
> How does this work ?
> 
> The coder hast copy&paste the renderers from 1.3 ? Always ?

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 5:53pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/16 "2006-09-03T17:53:41Z")

</div>

[…]

> I can image a plugin system like in XMMS, GIMP or other apps.  
> But it is hard for me how such a system could be used in SDL.
> 
> How is the state problem solved here ?

State is really only an issue when multiple independent “actors”  
manipulate the same context of a state machine style API.

If you run both an SDL internal renderer and a bunch of add-on library  
functions over the same OpenGL or Direct3D context, the problem is  
that you essentially have two “plugins” running in parallel, trying  
to output to the same “device”.

Most of the time, however, plugins run in series with the backend,  
and/or other plugins, and shared resources are accessed through  
interfaces that are designed for concurrent access (unlike OpenGL and  
Direct3D), so this situation is avoided.

> I look at how SDL inits the states  
> and copy these settings in my code ?

Only if you’re going to implement a new renderer over OpenGL or  
Direct3D. As long as you can do what you need without bypassing SDL,  
you’re fine just using the SDL API.

> What about people that do not use 3D ?

They just use the core SDL 2D API. (“opengl”, “d3d”, “software” and  
other renderers.)

Or, if they want polygons and stuff, they pull in SDL\_Advanced2D and  
set up the display with one of the extra renderers provided  
(“a2d\_opengl”, “a2d\_d3d” and “a2d\_software”). Then the core SDL API  
works as usual, but there are a bunch of extra rendering calls  
available as well.

> What about bugfixes in the SDL code ?

Well, tough luck! 😉

If you’re maintaining an extended SDL renderer, you get to maintain  
some 200-400 extra lines of code per supported target API. OTOH, you  
don’t have to track subtle changes in the renderers in the SDL core  
to ensure that your extended renderer still works with each new  
version of SDL. If your renderer works, it works, period.

So, this might actually make maintenance _easier_. Slightly more code,  
but it’s all yours, and there’s no one else randomly fiddling with  
your target context.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 19:34, Torsten Giebl wrote:

---

<div class="post-metadata">

**Author:** ![Simon3](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@Simon3](https://discourse.libsdl.org/u/Simon3)\
**Post date:** [September 3, 2006, 6:18pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/17 "2006-09-03T18:18:56Z")

</div>

> Why not do it properly while we’re at it? Unless there is a clean way  
> of getting “normal” SDL code to play along with code using OpenGL or  
> Direct3D directly, we’re not really improving the situation much  
> compared to SDL 1.2.

I agree, right now I feel as if the library would “behave” correctly  
with other library, until the developer decide they don’t anymore and  
start mixing render context and so on. But this is to be expected.  
There must be a way inside SDL to “regulate” the use of extra libraries.  
Right now it seems to be an almost perfect free-for-all.

I suggest leaving all this in the hands of the developer, give him a big  
warning that doing this and that can result in such kinds of problems,  
but of course, provide this developer with tools to assist him in making  
sure the problems never happen in production. I’m thinking about a way  
to monitor the state changes and a convenient way to deal with them  
(change them back, save state/restore state, etc…)

And besides, if new functionality is given to us to the price of some  
complication, I’m sure this is a deal some of us can agree with! 😉

Good luck,  
Simon

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [September 3, 2006, 7:40pm UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/18 "2006-09-03T19:40:01Z")

</div>

> > Why not do it properly while we’re at it? Unless there is a clean  
> > way of getting “normal” SDL code to play along with code using  
> > OpenGL or Direct3D directly, we’re not really improving the  
> > situation much compared to SDL 1.2.
> 
> I agree, right now I feel as if the library would “behave” correctly  
> with other library, until the developer decide they don’t anymore  
> and start mixing render context and so on. But this is to be  
> expected.

It depends on who the “developer” is, I suppose… There’s a  
difference between people who just want to use a bunch of high level  
libraries together to get the job done, and those who implement their  
own renderers. There are few reasons to do the latter. In fact, I can  
think of only two right now (and they’re closely related):

```
1) You want to implement extensions to the SDL 2D
   rendering API that cannot be layered cleanly
   above an existing SDL renderer. (That's what I'm
   trying to do right now.)

2) You're doing a full 3D game (OpenGL or Direct3D)
   and want to wire the SDL 2D calls into your
   engine, so you can integrate add-on libs that rely
   on these calls.

```

If you’re not trying to do something like the above, you should, as  
far as is realistically possible, _never_ have to worry about  
interoperability of SDL add-on libs, IMNSHO. It should Just Work™.  
(So we don’t have to respond to the same “It doesn’t work!” posts all  
the time. 😉

If you _are_ doing something like the aforementioned hardcore hacking,  
there’s really no way escaping the low level details. Fortunately, if  
you’re into that stuff, you most probably understand the nature of  
these issues. You just need the tools to deal with them properly.  
Also, by using these tools properly, it should be easy to end up with  
a final product that Just Works™ for others who just want to plug  
it into their SDL applications.

> There must be a way inside SDL to “regulate” the use of extra  
> libraries. Right now it seems to be an almost perfect free-for-all.

Well, yeah, when it comes to rendering in SDL 1.2, it’s pretty much  
only explicit and specific cooperation between libs, or nothing. (You  
_can_ layer GUI libs and stuff over glSDL, but that’s only because  
glSDL “fakes” polymorphism at compile time.)

[…]

> I’m thinking about a way to monitor the state changes and a  
> convenient way to deal with them (change them back, save  
> state/restore state, etc…)

It’s not too hard to keep track of changes, I think. SDL just keeps  
track of which renderer is using the context, and when another  
renderer takes over, a callback notifies the new renderer so it can  
restore anything that has been changed since the last time that  
renderer had the context.

However, unless similarities between the states as set up by different  
renderers are known, it becomes as simple as “Switched renderer?  
Restore all state data!”

I suppose one could analyze the state as initialized by each renderer,  
to optimize away pointless reloads of identical state data, but is it  
really worth the effort? It probably is IFF there is extremely  
frequent renderer changes - like one or two small primitives from  
each renderer, hundreds or thousands of times per frame. I doubt this  
will ever be an issue in actual application code, though I can  
certainly think of a bunch of ways of creating situations like  
that…

So, perhaps all we need to do is keep track of which renderer is using  
each context, and notify the “new” renderer whenever there is a  
switch. (That is, call it’s ReinitContext() method or something.)

> And besides, if new functionality is given to us to the price of  
> some complication, I’m sure this is a deal some of us can agree  
> with! 😉

Well, yeah, but I think it’s generally a good idea to try to simplify  
things rather than complicate them. 😉

Or rather, I think it’s possible to pretty much bridge the 2D/3D gap  
without making SDL harder to use. It’s not a trivial problem, but  
that only makes it more important that SDL helps developers to deal  
with it.

All that said, I still think runtime plugin renderers is a good idea.  
It can be used to solve the “extended renderer” problem in an  
efficient and rock solid way (by simply not having multiple renderers  
on one context) - but it can also be used to implement support for  
new targets and other things that you otherwise cannot do without  
modifying SDL.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
| [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
| [http://audiality.org](http://audiality.org) - Music/audio engine |  
| [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
'-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --'On Sunday 03 September 2006 20:18, Simon wrote:

---

<div class="post-metadata">

**Author:** ![Bob\_Pendleton](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/b/9de053/32.png) [@Bob\_Pendleton](https://discourse.libsdl.org/u/Bob_Pendleton)\
**Post date:** [September 4, 2006, 2:13am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/19 "2006-09-04T02:13:15Z")

</div>

> > > A simple solution would be some kind of mutual notification  
> > > interface, so that SDL renderers can tell the application when  
> > > they’ve messed with the API state, and vice versa.
> > 
> > Alternately, you can use glPushAttrib().
> 
> Well, the hard part is figuring out when to do this… I can’t see any  
> sensible way to automate it, so for all practical matters, it’s  
> “manual control” from the application side. Error prone and hard to  
> debug - especially if the offending code is not your own, but inside  
> various add-on libs that you’re trying to use together.

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. This way the context stays the same from the end users point of  
view. Someone is going to say that pushing and popping the context is to  
time consuming, I don’t believe it.

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

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

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

```
	Bob PendletonOn Sun, 2006-09-03 at 11:47 +0200, David Olofson wrote:

```

> On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:

> //David Olofson - Programmer, Composer, Open Source Advocate
> 
> .------- [http://olofson.net](http://olofson.net) - Games, SDL examples -------.  
> | [http://zeespace.net](http://zeespace.net) - 2.5D rendering engine |  
> | [http://audiality.org](http://audiality.org) - Music/audio engine |  
> | [http://eel.olofson.net](http://eel.olofson.net) - Real time scripting |  
> ‘-- [http://www.reologica.se](http://www.reologica.se) - Rheology instrumentation --’
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)

–  
±-------------------------------------+

- Bob Pendleton: writer and programmer +
- email: Bob at [Pendleton.com](http://Pendleton.com) +
- web: [www.GameProgrammer.com](http://www.GameProgrammer.com) +
- [www.Wise2Food.com](http://www.Wise2Food.com) +
- nutrient info on 7,000+ common foods +  
±-------------------------------------+

---

<div class="post-metadata">

**Author:** ![icculus](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/icculus/32/81_2.png) [@icculus](https://discourse.libsdl.org/u/icculus)\
**Post date:** [September 4, 2006, 7:30am UTC](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815/20 "2006-09-04T07:30:57Z")

</div>

> Yeah… Rename SDL\_LoadBMP() as SDL\_LoadSurface() (or something), and  
> convert SDL\_image into a plugin that adds support for more file  
> formats?

And this is where I go “stop, stop, god, please stop!”

–ryan.

[Next page](https://discourse.libsdl.org/t/sdl-1-3-and-rendering-api-state-management/13815.md?page=2)