[OLPC-Games] GTK+ video target for SDL, first attempt.

[Kent Quirk]

Wow, Ryan, this looks like a good approach. I'm hoping that some of the 
people more intimate with Sugar than I am will chime in with additional 
commentary.

The things I think we care about most are:

* An unmodified SDL application should "play nice" with Sugar and not do 
anything inappropriate
* It should be relatively easy to modify an SDL app to do everything 
Sugar wants an app to do
* It should be possible to tweak PyGame so that an unmodified PyGame app 
does everything right
* There should be some way to get PyGame and PyGTK to cooperate. I don't 
know enough yet to know how much of a problem that will be, except maybe 
a conflict between two main loops, but I hope that we'll be able to work 
out whatever problems there are.

We have some Google Summer of Code students who were planning to work on 
all this stuff when they finish class for the year, and that's about 
when my availability will improve as well. It's fantastic that you're 
giving us a head start. If it turns out you have all of this out of the 
way by the time they're ready, there's plenty more for them to do in the 
areas of PyGame extensions and support for the OLPC-specific hardware. 
But if you need or want assistance from them, it will be available in a 
couple of weeks.

    Kent

Ryan C. Gordon wrote:
> This email is mostly just a request for comments, including comments 
> like "this work isn't the right way to go," before I go further. Lots of 
> this is broken still, lots more is speculative in nature.
>
> I've written the initial parts of a GTK+ video target for SDL. This 
> removes the direct dependence on X11 from the library and makes it 
> easier to hook into Sugar. The goal is to make it work without any 
> source code changes (or even a recompile) needed in third-party apps 
> that just want to use SDL, and make it easier for apps that want to use 
> SDL but also hook into the OLPC features.
>
> Video performance on my Linux desktop is almost identical to the X11 
> target...sometimes a few frames per second faster, sometimes a few 
> slower, depending on the run.
>
> Comments and patches welcome.
>
>
> To use:
>
> - Get the latest SDL-1.2-olpc from Subversion:
>       svn co http://svn.libsdl.org/branches/SDL-1.2-olpc
>       (or "svn update" from inside the SDL-1.2-olpc dir, later)
>
> - Build it with GTK+ support:
>       cd SDL-1.2-olpc
>       ./autogen.sh
>       ./configure --enable-video-gtk
>       make
>       sudo make install
>
> - Run your favorite existing SDL app with that library:
>       SDL_VIDEODRIVER=gtk ./my-sdl-application
>
> (By default, you'll get the x11 target, so you'll want to use the 
> SDL_VIDEODRIVER=gtk environment variable. The default will change later, 
> but this is handy right now for switching between the two targets if you 
> want to decide if something is a bug.)
>
> When your app runs, instead of talking directly to X11, it'll create a 
> GTK+ window. Beyond the bits that still aren't implemented, it should 
> pretty much work as before if everything worked correctly.
>
>
> Event handling:
>
> Eventually this will allow you to just into the usual GTK+ event loop in 
> several ways.
>
> First, the SDL_SYSWMEVENT will be available, but will pass on GTK+ 
> events, for people that want to "speak GTK+" but use the usual SDL event 
> loop algorithms.
>
> Perhaps better: you'll be able to connect signals for the things you 
> care about, like a standard GTK+ program...the SDL event queue will 
> deliver the events it usually does via SDL_PollEvent(), etc, but pumping 
> the SDL event queue will fire GTK+ signals for any other, non-standard 
> events you care about. In addition, SDL doesn't stop GTK+ from passing 
> on signals that SDL cares about, either, so if you want to connect up 
> standard GTK+ handlers for motion-notify-event, etc, you still can. The 
> only signal SDL stops is delete-event on the top level window, since the 
> default GTK+ handler destroys it, you can catch this as SDL_QUIT, though.
>
> The general plan is that you have your standard SDL app, but you can add 
> a small piece of code to catch Sugar-specific events:
>
>     SDL_Init(SDL_INIT_VIDEO);
>     screen = SDL_SetVideoMode(640, 480, 0, 0);
>
>     #ifdef OLPC   /* (this doesn't work in the current build...) */
>     {
>         SDL_SysWMinfo info;
>         if (SDL_GetWMInfo(&info))
>         {
>              gtk_signal_connect(GTK_OBJECT(info.gtkdrawingarea),
>                         "some-sugar-specific-signal",
>                         GTK_SIGNAL_FUNC(my_sugar_signal_handler), data);
>         }
>     }
>     #endif
>
>     while (SDL_PollEvent(&event))
>     {
>         /* event.type will be an SDL event, but my_sugar_signal_handler()
>            may have been called during SDL_PollEvent()... */
>     }
>
>     /* ...etc... */
>
>
>
> Beware the following:
>
> - There are no hardware YUV overlays...my understanding is that the 
> laptops have them with the Xvideo extension, but I didn't see any 
> obvious way to expose this via GDK. SDL still lets you use them in the 
> usual way, it'll just convert them to RGB data on-the-fly at the cost of 
> CPU time.
>
> - No OpenGL for obvious reasons. SDL_SetVideoMode(..., SDL_OPENGL) will 
> just flat out fail, returning a NULL surface. This is true of SDL's X11 
> target on the laptops, too.
>
> - No "fullscreen" ... it'll always give you a window, even with the 
> SDL_FULLSCREEN flag requested. I'm not sure what this will do in the 
> Sugar environment...this will just eventually force it to "fullscreen" 
> in the way the laptop would expect, but I haven't decided on the 
> specific semantics of that, yet.
>
> - Input grabbing isn't hooked up yet.
>
> - Keyboard (!) isn't hooked up yet. You'll only get mouse events and 
> SDL_QUIT.
>
> - Sugar-specific bits, like how to access the event queue from your app, 
> are not hooked up yet. This will be done soon.
>
> - Hasn't been tested on real hardware or emulator yet.  :)    ...this is 
> still isn't feature complete, so I'm still working on a Ubuntu desktop. 
> If something doesn't work on the laptop that works on a desktop box, 
> it's definitely a bug to be addressed.
>
> --ryan.
>
> _______________________________________________
> Games mailing list
> Games at laptop.org
> http://mailman.laptop.org/mailman/listinfo/games
>
>   


-- 
------------------------------------------------------------
Kent Quirk           I'm making a game about global warming.
Game Architect                        Track the progress at:
CogniToy                http://www.cognitoy.com/meltingpoint