The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi

My SDL app hogs the CPU unless in a state where I'm waiting for user input. Since I'm using SDL_PollEvent, I
never miss an event, but CPU is at 100% the whole time.

If I put a 100ms delay every pass of the loop, CPU drops to ~25% which is fine.

So....how do I get CPU usage down to the ~25% figure without using a delay in the loop?

This isn't a Windows app, just a console app.

Any help muchly appreciated!

Ed




__________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080208/b0f94d3f/attachment.htm

On Friday 08 February 2008 13:43:02 Edward Byard wrote:

It's hard to say without knowing how you are using SDL_PollEvent. If I had to
guess, I say you are doing a spin-loop on it. In case you missed it,
SDL_PollEvent returns right away regardless if events are in the queue. If
you are constantly calling SDL_PollEvent, then I'd fully expect it to behave
as you said.

Have a look at SDL_WaitEvent() and see if it fits into your program. If you
aren't sure, can you post an example of how you read/poll the events?

Alvin

Am 08.02.2008 um 19:43 schrieb Edward Byard:


Hi,

This is an issue we were also working on at our project (OpenLieroX, a
game) recently.

Like Alvin said, use SDL_WaitEvent() where you can. You have to
separate a bit code which has to be executed frequently and code that
only has to be executed if an event occurs (for example the user has
pressed a key or your application got a quit signal or a socket
received some data).

Though, if your app is not event-based this needs some work to do. In
other cases, a delay is the correct way to let your app sleep a bit.
It means that you give some time away for other processes which means
that you don't use 100% CPU time.

X% CPU time just means that your application always do something and
never sleeps.

(In some implementations, SDL_WaitEvent() simply is a loop where it
checks SDL_PollEvent() and if no event has occurred, it just sleeps a
bit and tries again.)

We made it like this: All menu code uses SDL_WaitEvent() and only
while the game itself is running, we use SDL_PollEvent() with a
SDL_Delay(). You can set a MaxFPS value and SDL_Delay() sleeps exactly
so long that the FPS is not higher than the MaxFPS value.

Greetings,
Albert

I think I've sorted it.

I used to have a while (SDL_PollEvent) which is now an if (SDL_PollEvent) which handles the input,
and then put a 50ms delay outside this which brings the CPU down to 30%.

A bit more code re-organising and using a delay in some major animation work has got CPU usage down to
30% and made the system more stable and, it seems, the animation is much smoother.

Thanks for your advice!

Ed

----- Original Message ----
From: Alvin <alvinbeach at gmail.com>
To: sdl at lists.libsdl.org
Sent: Friday, 8 February, 2008 5:55:24 PM
Subject: Re: [SDL] CPU usage

On
Friday
08
February
2008
13:43:02
Edward
Byard
wrote:
Hi
My
SDL
app
hogs
the
CPU
unless
in
a
state
where
I'm
waiting
for
user
input.
Since
I'm
using
SDL_PollEvent,
I
never
miss
an
event,
but
CPU
is
at
100%
the
whole
time.
If
I
put
a
100ms
delay
every
pass
of
the
loop,
CPU
drops
to
~25%
which
is
fine.
So....how
do
I
get
CPU
usage
down
to
the
~25%
figure
without
using
a
delay
in
the
loop?
This
isn't
a
Windows
app,
just
a
console
app.
Any
help
muchly
appreciated!
Ed

It's
hard
to
say
without
knowing
how
you
are
using
SDL_PollEvent.
If
I
had
to
guess,
I
say
you
are
doing
a
spin-loop
on
it.
In
case
you
missed
it,
SDL_PollEvent
returns
right
away
regardless
if
events
are
in
the
queue.
If
you
are
constantly
calling
SDL_PollEvent,
then
I'd
fully
expect
it
to
behave
as
you
said.

Have
a
look
at
SDL_WaitEvent()
and
see
if
it
fits
into
your
program.
If
you
aren't
sure,
can
you
post
an
example
of
how
you
read/poll
the
events?

Alvin
_______________________________________________
SDL
mailing
list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org






___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080208/9d12fdec/attachment.htm

Hello !




The problem is that the more CPU cycles your app eats, the
less CPU cycles are there for your app/game/programm.

Maybe you don't need to use SDL_Delay with a delay that
high, have you tested it with SDL_Delay(1) or SDL_Delay (10) ?


But the best thing indeed is to look at the actual frames,
if you would possibly get 80 FPS and need only 60 FPS
then give the 20FPS free with SDL_Delay.


CU

Hello !




That was wrong i meant the more CPU cycles your app eats, the
less CPU cycles are there for X11, Win32, Quartz to update the screen.


CU

On Feb 8, 2008 10:55 AM, Alvin <alvinbeach at gmail.com> wrote:
IMO, there's a pretty major gap in functionality between WaitEvent and
PollEvent. Carbon's WaitNextEvent has a timeout that you can set
appropriately, what we need is something like that for SDL. (Aside
from Edward's use case, events may not be the only thing the app wants
to block on.)
-:sigma.SB

Hey,
fullscreen, you shouldn't ever worry about the CPU usage, considering there
won't be any other programs in use while it's running. If you really feel
you need a delay, use SDL_Delay( 1 ) which will give up the smallest
timeslice available, while still giving your program the most attention.
Again, I can never stress enough that if you are making a fullscreen game,
you should never *need* a delay

Alex

On Feb 8, 2008 5:22 PM, Solra Bizna <sbizna at tejat.net> wrote:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080208/bf696fae/attachment.html

Can't say I agree with that. Many are the times when I've left lengthy usenet downloads going in the background while I brought up a game. Sure 'nuff the downloads dropped to a very noticeable crawl.

Lil

I agree. Sure it will take more time to implement correctly, but sharing
system resources including (especially?) cpu time is the right thing to do,
even for full-screen apps. Consider if somebody wants to play your game on
a laptop via battery power. Obviously they wouldn't be able to play very
long if your game just sits in a loop without yielding. Maybe people don't
usually play games on battery, but maybe the reason is because most games
are not implemented correctly and do burn down the battery needlessly. Just
make your app do the right thing. Maybe most users won't notice how nicely
your app shares the system, but I think you're bound to make a few people
happier.

Chaz

----- Original Message -----
From: "Lilith Calbridge" <lilith at dcccd.edu>

On Feb 8, 2008 4:50 PM, Alex Barry <alex.barry at gmail.com> wrote:
Yes, but SDL is also useful for writing other applications, including
applications that require some animation or need to respond to other
asynchronous events but don't want to grab the CPU by its horns.
(Before someone says "use threads," not all SDL ports support threads.)
-:sigma.SB

Perhaps I should have added to why you shouldn't use a delay. Most games
hog CPU power, but there is a handy thing called v-sync, which adds a tiny
delay to make sure the screen is essentially ready. This still keeps CPU
usage high (which is good for your game), but doesn't hog it

hope that helps

On Feb 8, 2008 8:11 PM, Solra Bizna <sbizna at tejat.net> wrote:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080209/03518eae/attachment.html