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

Ryan C. Gordon icculus at icculus.org
Thu Apr 19 03:52:23 EDT 2007


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.



More information about the Games mailing list