[SDL] SDL 1.3 and rendering API state management

Antonio SJ Musumeci asm3072 at njit.edu
Sun Sep 3 06:57:53 PDT 2006

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 

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.
> 		+ 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 - 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  --'
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

More information about the SDL mailing list