Unacceptable framerates

SDL Development
1

Hi!

I’ve just decided to start using SDL as for all my lowlevel multimedia
stuff, but a few tests have gotten me quite worried.

I’m developing under Linux with XFree86 4.0.1, Celeron 466, NVidia TNT2
Ultra with 32MB Ram, bucket loads of Ram, etc.

What this all boils down to is that SDL on my platform should be using the X
DGA extensions for rendering and should also support all the hardware
rendering options: SDL_HWPALETTE | SDL_DOUBLEBUF | SDL_HWSURFACE

However this does not seem to be the case. What’s more, my SDL tests seem to
be crappy even when compared to my xlib program’s performance.

To test this I created a small eyecandy program in 3 versions. I wrote one
that uses xlib for rendering in a window, a version that uses X’s DGA
extensions directly and a version that uses the SDL library for getting a
framebuffer.

My results are as follows (with some mp3’s playing in the background, etc. ,
so this is just giving an idea of performance):

version resolution performance==================================================================
xlib 800x600x32bpp 27.931034 fps in 29 seconds
sdl (windowed) 800x600x8bpp 18.867925 fps in 53 seconds
sdl (windowed) 800x600x24bpp 9.009009 fps in 111 seconds
sdl (windowed) 800x600x32bpp 22.222222 fps in 45 seconds
sdl (fullscreen) 800x600x8bpp 19.607843 fps in 51 seconds
sdl (fullscreen) 800x600x32bpp 22.222222 fps in 45 seconds
dga (fullscreen) 800x600x8bpp 200.000000 fps in 50 seconds

As you can see, sdl windowed is performing a little bit worse than xlib at
the same resolution which is expected since I just redraw the object in
black in my xlib version (since it’s faster - xlib’s FillRectangle function
is f***ing slow) and in the sdl version I didn’t bother. Also the palette
emulation explain the degraded performance in 24bpp and 8bpp.

What bothers me though is the fullscreen modes. The sdl is MORE THAN 10
TIMES SLOWER!!! In fact, it compares to the windowed version, so it’s
CLEARLY not using DGA at all, nevermind hardware optimizations.

A quick look at the included sdl example programs and my own investigation
also leads me to believe that sdl uses the system memory for surfaces even
though I’m explicitly setting the mode with SDL_HWSURFACE.

I’m including my test programs so you can have a look at them.

Could somebody PLEASE tell me what is wrong? I’d really like to use SDL as a
backend. It’s API is well designed and it doesn’t intrude (i.e. it doesn’t
actually try and implement some crappy drawing routines for me, etc.) so I’m
quite happy with it if only it would work properly!

PS:

If you run the sdl and dga test programs you will see that the colors is
either wrong or you don’t see anything at all and there is no event handling
(it just runs for a certain amount of frames). Don’t worry, it’s test
programs (: I was too lazy/didn’t get around to actually setting up a
correct palette and/or getting event handling to work properly.

PPS:

A quick note about compiling. Remember to change CC in the Makefiles from
colorgcc to gcc otherwise the compile will fail. The dga and sdl stuff also
have a gfx subdirectory - that’s the lowlevel drawing routines. change to
the directory and type make before attempting to compile.

–

Regards
Abraham

Committees have become so important nowadays that subcommittees have to
be appointed to do the work.

Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks
P.O. Box 3472, Matieland, Stellenbosch, 7602
Cell: +27 82 565 4451 - Tel: +27 21 887 8703
Http: http://www.frogfoot.net
Email: @Abraham_vd_Merwe

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl.tar.gz
Type: application/octet-stream
Size: 20942 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20001228/40b252b1/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: xlib.tar.gz
Type: application/octet-stream
Size: 10176 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20001228/40b252b1/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: dga.tar.gz
Type: application/octet-stream
Size: 23318 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20001228/40b252b1/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20001228/40b252b1/attachment.pgp

2

What this all boils down to is that SDL on my platform should be using the X
DGA extensions for rendering

Because SDL chooses the video driver before setting the video mode, you
need to tell SDL to use the DGA video driver via an environment variable.

This is in the FAQ:
http://www.libsdl.org/faq/FAQ-Linux.html#LINUX_12

SDL 1.3 will have a redesigned driver architecture, and we’ll try to find
a better way of doing things.

Thanks for the test code, BTW. :slight_smile:

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

3

What this all boils down to is that SDL on my platform should be using the X
DGA extensions for rendering and should also support all the hardware
rendering options: SDL_HWPALETTE | SDL_DOUBLEBUF | SDL_HWSURFACE

Assuming SDL was build with DGA support configured, did you try
setting SDL_VIDEODRIVER=dga?

My results are as follows (with some mp3’s playing in the background, etc. ,
so this is just giving an idea of performance):

This is no flame, but if you can’t even bother to turn off everything else
in the background, you cannot be even remotely serious about benchmarking

xlib 800x600x32bpp 27.931034 fps in 29 seconds
sdl (windowed) 800x600x8bpp 18.867925 fps in 53 seconds
sdl (windowed) 800x600x24bpp 9.009009 fps in 111 seconds
sdl (windowed) 800x600x32bpp 22.222222 fps in 45 seconds
sdl (fullscreen) 800x600x8bpp 19.607843 fps in 51 seconds
sdl (fullscreen) 800x600x32bpp 22.222222 fps in 45 seconds
dga (fullscreen) 800x600x8bpp 200.000000 fps in 50 seconds

(since it’s faster - xlib’s FillRectangle function
is f***ing slow) and in the sdl version I didn’t bother.

I don’t think XFillRectangle() is slow. In particular I would expect
it to be considerably faster than SDL_FillRectangle() for SDL targets
where it isn’t accelerated, such as X11. I also note that you are
using XDrawLines() in the xlib version, which is commonly accelerated

Also the palette
emulation explain the degraded performance in 24bpp and 8bpp.

I’m not sure what you have measured. You seem to be requesting 8bpp in your
call to SDL_SetVideoMode(), which means that you will get an emulated
surface if there is no 8bpp visual available. But your benchmark data
suggests that 32bpp is faster than 8bpp, which contradicts this.

The only way the table above would make sense is if you are using
an 32bpp surface, and the numbers in the table refers to the physical depth
(but why then ask for a HWPALETTE?)

A quick look at the included sdl example programs and my own investigation
also leads me to believe that sdl uses the system memory for surfaces even
though I’m explicitly setting the mode with SDL_HWSURFACE.

The DGA and X11 drivers are separate in SDL. X11 won’t give you
hardware surfaces