[OLPC-Games] SDL improvements...

[Ryan C. Gordon]

> I think it may be a good idea to add an RGB overlay backend for SDL
> (probably as an option in the X11 backend). The hardware has a scaler
> so the games can render using smaller resolution but still have
> full-screen display. Otherwise the 1200x900 resolution could be a
> bottleneck for high-fps games.

So here's a potentially silly question:

Just because there IS an X server, should we be moving forward as if 
there isn't?

I'm reminded of when gtkfb showed up around 2000, and the developers 
found most GTK+ applications would work on fbcon with that project, but 
a few Gnome apps would fail because they would occasionally bypass GDK 
and expect to find an X11 connection.

So is the presence of an X server on the OLPC machines just an 
implementation detail, or can we count on it always being there? Is it 
considered bad manners to use xlib if you aren't a core component like GTK+?

It could make sense to write a "gtk" video target for SDL, so it creates 
a GTK+ window when SDL_SetVideoMode() is called, and uses 
gdk_draw_image() during SDL_UpdateRect(). If GDK is smart enough to use 
the MIT-SHM extension, it would probably be around as fast as the 
current SDL X11 code, without the cruft and baggage we carry for legacy 
X servers and extensions, without the direct xlib dependency...and 
without the SDL_WINDOWID hack currently used to get SDL into a GTK+ window.

 From my brief reading of the Cairo documentation, I think targeting 
Cairo as a backend in SDL is just not feasible...it looks like a lot of 
unacceptable overhead, in the same way that a "bad" API like QuickDraw 
makes more sense for SDL on Mac OS X than Quartz; SDL wants to deal with 
framebuffers, not drawing primitives.

Also, is it also considered bad manners to talk to ALSA directly, or 
should we go through, I don't know, GStreamer or whatever instead?

--ryan.