[SDL] SDL 1.3 and rendering API state management

[David Olofson]

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