Load limiting in SDL?

SDL Development
1

I have been watching the load on my (and other programs) that I
have written with SDL. It seems that the SDL programs will
not eat a whole processor and try to keep the system load around 1.
Are the libraries written this way? If so, why? My second processor
could be handling X and the sound thread, but it seems to have been
rendered moot.

Frank Samuelson

2

I have been watching the load on my (and other programs) that I
have written with SDL. It seems that the SDL programs will
not eat a whole processor and try to keep the system load around 1.
Are the libraries written this way? If so, why? My second processor
could be handling X and the sound thread, but it seems to have been
rendered moot.

The second processor is more than likely handling the audio, but audio
processing usually takes only 3-5% of the CPU.

SDL isn’t currently set up to do asynchronous X server blits. I experimented
with this before, and you end up with really bad tearing when you and the X
server are both writing to the shared memory at the same time.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

3

This is sortof related to providing a method for seperate Xsync calls
though. What about the SDL_DEFER_SYNC option to a SDL window, then
providing a seperate api function that calls the sync?
This would only be directly relavent to the X platform, it would be a NOOP
on other platforms.–
Brian

The second processor is more than likely handling the audio, but audio
processing usually takes only 3-5% of the CPU.

SDL isn’t currently set up to do asynchronous X server blits. I experimented
with this before, and you end up with really bad tearing when you and the X
server are both writing to the shared memory at the same time.

4

This is sortof related to providing a method for seperate Xsync calls
though. What about the SDL_DEFER_SYNC option to a SDL window, then
providing a seperate api function that calls the sync?
This would only be directly relavent to the X platform, it would be a NOOP
on other platforms.

I’d be interested in evaluating patches. I played with it quite a bit and
found that most of the tests needed to write to the display again almost
immediately, but…

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

5

Frank Samuelson wrote:

I have been watching the load on my (and other programs) that I
have written with SDL. It seems that the SDL programs will
not eat a whole processor and try to keep the system load around 1.
Are the libraries written this way? If so, why? My second processor
could be handling X and the sound thread, but it seems to have been
rendered moot.

Frank Samuelson

Perhaps you’re polling for events, so your program sits in a tight loop
constantly calling SDL to see if any events are available. Instead of
using SDL_PollEvent use SDL_WaitEvent in your event polling thread…–

| Rafael R. Sevilla @Rafael_R_Sevilla |
| Instrumentation, Robotics, and Control Laboratory |

College of Engineering, University of the Philippines, Diliman
6

Sam Lantinga wrote:

The second processor is more than likely handling the audio, but audio
processing usually takes only 3-5% of the CPU.

SDL isn’t currently set up to do asynchronous X server blits. I
experimented with this before, and you end up with really bad
tearing when you and the X server are both writing to the shared
memory at the same time.

Just add lock/unlock to surfaces, and make lock give an error when the
surface is busy. Now, I see people doing busy-waits on a lock function,
which is a bad idea for two reasons: busy-waits are evil, and the X
server will notify the application that it is finished using the memory
through an event, so you would have to service the event queue in the
lock function (eeks!). Document the semantics properly.–
Pierre Phaneuf
Systems Exorcist