Hello folks,
I’m pretty new to SDL. I’m writing an application that requires a
short series of PAL resolution images (768*576 pixels, RGB 24bpp)
present in memory to an X window at 25 fps. This is a GTK
application, and I’d been using the GDK functions (which I
presume to be more or less wrappers around Xlib functions) to
render the RGB data to screen. Since I couldn’t get a framerate
of more than about 19 fps this way, someone suggested that I take
a look at SDL.
Which is what I did. It’s simple enough: Store my “movie” as a
sequence of SDL_Surfaces, then render each one to screen by first
a call to SDL_BlitSurface() followed by a SDL_UpdateRect(). To my
surprise, this approach is considerably slower than using GDK. I
found SDL_UpdateRect() to be the culprit: This function call
alone takes more than 80ms (as opposed to the less than 60ms it
takes gdk_pixbuf_render_to_drawable() which I had been using
before). The SDL_BlitSurface() call, which I had supposed to do
all the real work, takes about 7ms. This really puzzles me
because I had thought that SDL did some low-level magic to really
make things fly.
I’ve trying to create the SDL target surface with different flags to
SDL_SetVideoMode() (SDL_HWSURFACE vs. SDL_SWSURFACE, with or without
SDL_DOUBLEBUF), and I tried SDL_Flip() instead of SDL_UpdateRect. The
differences in performance arte neglible. What’s the point of creating the
target surface in the video card’s memory if it still takes such a long time to
get it to the screen?
OK, here’s my question, finally: What am I doing wrong?
I know it should be possible to go faster using SDL, after all,
mplayer works fine on this computer (dual 700MHz Pentium, Matrox
G400). I also profiled the SDL demo suite programs and found that
in all of them the SDL_UpdateRect() call took as long as in my
program (in proportion to the size of the area being updated).
This is Linux 2.2.18, X 4 something.
Thanks for any hints,
–Daniel