I gather the main improvement in this implementation would be
taking advantage of texture memory on the video card and
Yep - or actually, we have to keep surfaces in VRAM to have OpenGL
accelerate anything at all in the normal case. (Some drivers will
probably make use of DMA to accelerate glWritePixels() if you use a
h/w supported pixel format, but so far, I’ve never seen that, at
least not on a Linux driver.)
potentially adding rotated blits to SDL.
Maybe eventually, but that’ll be if/when rotated blits are a part of
the official SDL API, implemented (one way or another) on all
backends. The problem is that rotated blits take a lot more power
than plain blits when implemented in software, so using them
effectively makes your code depend on h/w acceleration for proper
operation (as in usable framerates) - and then you’re probably better
off using OpenGL directly.
You could of course think of glSDL as a handy OpenGL wrapper, but I
think it’s way too low level to make sense. Could happen that a pure
accelerated 2D lib is forked off of glSDL eventually, though…
This sounds very
promising. It would probably require some extensions to SDL to be
able to manipulate what goes in and what doesn’t go into texture
ram.
That “extension” is already in place; the SDL_HWSURFACE flag. Only
blits from hardware surfaces to the display surface are OpenGL
accelerated.
This is actually more accidental than intentional; we can’t reliably
accelerate blits from software surfaces, as there is no requirement
that they are locked when modified. More specifically, we can’t tell
when you modify a s/w surface, so we can’t cache it in VRAM.
Note that glSDL/wrapper (found here: http://olofson.net/mixed.html)
does accelerate blits from any type of surface - but indeed, it
breaks if you modify surfaces without locking/unlocking them, which
makes it slightly incompatible with the official SDL API.
Using texture ram on a often modified/read surface would
decrease performance
Depends… With good drivers, uploading a texture is at least as fast
as an optimal SDL s/w blit - and if the surface has an alpha channel,
the total performance will be very much higher than doing it all in
software.
so it sounds like they will have to extend SDL
a little further to discriminate between static and volatile
surfaces.
Actually, I suggested an extension SDL_InvalidateRect() that would
tell the backend that a specific part of a surface has been modified.
This would avoid the requirement to update the whole surface/texture
if only part of it was changed. This was actually in one SDL release,
but was backed out again. Probably just as well, as it needs explicit
application support, is irrelevant to most backends, and probably
isn’t all that useful. (How often do you actually do procedural fx in
a small area of a surface? I could use that for the new radar display
in Kobo Deluxe, but I think it’s a rather unusual case.)
Anyway, I’m thinking about it way too much 
Unlikely. 
This is quite tricky stuff, since the SDL API wasn’t really designed
with this type of backends in mind. I think we got it mostly right
now, but the problem is that there is a direct conflict between being
totally true to the SDL API, and allowing your average SDL
application to be fully accelerated. :-/
//David Olofson - Programmer, Composer, Open Source Advocate
ps. I’m the author of the original glSDL/wrapper, which has been
converted into an SDL backend by Stephane Marchesin, with some
occasional help/interference from me.
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 13 August 2004 08.39, grembo wrote: