Input polling precision and CPU lightening

Hello,

I have followed the SDL Library Documentation to process joypad event
polling, and I do this :

while(run) {
while(SDL_PollEvent(&event)) {
// process event
}
}

Then the CPU is nearly 100 % involved. Is the only way of lightening it
to wait in the loop ?
It seems that it’s what SDL_WaitEvent does but I have read it "samples"
the input flow by waiting 10 ms between calls to SDL_PollEvent.
So I guess there is no way to wait exactly for the amount of time
separating two events, and which is not necessarily a multiple of 10
ms.

Can anyone share his/her experience on the subject ?

Thank you,

Guillaume Denis

Hello,

I have followed the SDL Library Documentation to process joypad
event polling, and I do this :

while(run) {
while(SDL_PollEvent(&event)) {
// process event
}
}

Then the CPU is nearly 100 % involved. Is the only way of
lightening it to wait in the loop ?

If that uses around 100% of the CPU, I assume you’re either doing that
in a pure event handling thread, or (of there is rendering code in
that loop as well) that you’re using a platform, driver or video mode
that does not support retrace sync’ed page flipping.

I can see why you’d want to use a separate event thread. That allows
you to timestamp input events with arbitrary accuracy regardless of
the rendering frame rate. However, most of the time, if you need low
latency/high accuracy input handling, you also need a relatively high
frame rate for a usable end result.

I’d recommend doing everything (except sound, for various reasons) in
a single thread. It’s more robust, simpler, and tends to work well on
all platforms, including those that have threading issues or don’t
support threading at all.

It seems that it’s what SDL_WaitEvent does but I have read it
"samples" the input flow by waiting 10 ms between calls to
SDL_PollEvent. So I guess there is no way to wait exactly for the
amount of time separating two events, and which is not necessarily
a multiple of 10 ms.

That would depend on the underlying platform, at least in theory… On
most platforms, you can block properly when waiting for events, but
the problem is that on many of them, you can’t have a single thread
block on multiple different sources at once. (Traditional Un*x
problem.)

As a result of this, (AFAIK) SDL always polls for events every 10 ms.
IIRC, it does this no matter how the application reads events, so you
won’t get improved accuracy by polling from the application.

DISCLAIMER: This may not apply to all platforms. I could even be
mixing things up completely.

Read the SDL source if you want to know exactly what happens on each
platform you care about.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Monday 13 December 2004 14.21, Guillaume Denis wrote:

Thanks for your answer,

If I’m polling in a separate thread it’s because I am using SDL through
a native call in a Java application and I don’t want to make native
calls within the main loop. Another thing is that the events trigger
sounds (notes, chords) and I want the latency to be as low as possible.

I guess I will have to find a good balance between CPU use and latency
adjusting the duration of the pause (SDL_Delay(x)) in the event polling
thread. But ‘x’ may not be the same on different machines…

Guillaume

Le 13 d?c. 04, ? 21:00, sdl-request at libsdl.org a ?crit :>

Hello,

I have followed the SDL Library Documentation to process joypad
event polling, and I do this :

while(run) {
while(SDL_PollEvent(&event)) {
// process event
}
}

Then the CPU is nearly 100 % involved. Is the only way of
lightening it to wait in the loop ?

If that uses around 100% of the CPU, I assume you’re either doing that
in a pure event handling thread, or (of there is rendering code in
that loop as well) that you’re using a platform, driver or video mode
that does not support retrace sync’ed page flipping.

I can see why you’d want to use a separate event thread. That allows
you to timestamp input events with arbitrary accuracy regardless of
the rendering frame rate. However, most of the time, if you need low
latency/high accuracy input handling, you also need a relatively high
frame rate for a usable end result.

I’d recommend doing everything (except sound, for various reasons) in
a single thread. It’s more robust, simpler, and tends to work well on
all platforms, including those that have threading issues or don’t
support threading at all.

It seems that it’s what SDL_WaitEvent does but I have read it
"samples" the input flow by waiting 10 ms between calls to
SDL_PollEvent. So I guess there is no way to wait exactly for the
amount of time separating two events, and which is not necessarily
a multiple of 10 ms.

That would depend on the underlying platform, at least in theory… On
most platforms, you can block properly when waiting for events, but
the problem is that on many of them, you can’t have a single thread
block on multiple different sources at once. (Traditional Un*x
problem.)

As a result of this, (AFAIK) SDL always polls for events every 10 ms.
IIRC, it does this no matter how the application reads events, so you
won’t get improved accuracy by polling from the application.

Thanks for your answer,

If I’m polling in a separate thread it’s because I am using SDL through
a native call in a Java application and I don’t want to make native
calls within the main loop. Another thing is that the events trigger
sounds (notes, chords) and I want the latency to be as low as possible.

I guess I will have to find a good balance between CPU use and latency
adjusting the duration of the pause (SDL_Delay(x)) in the event polling
thread. But ‘x’ may not be the same on different machines…

Guillaume

Le 13 d?c. 04, ? 21:00, sdl-request at libsdl.org a ?crit :>

Hello,

I have followed the SDL Library Documentation to process joypad
event polling, and I do this :

while(run) {
while(SDL_PollEvent(&event)) {
// process event
}
}

Then the CPU is nearly 100 % involved. Is the only way of
lightening it to wait in the loop ?

If that uses around 100% of the CPU, I assume you’re either doing that
in a pure event handling thread, or (of there is rendering code in
that loop as well) that you’re using a platform, driver or video mode
that does not support retrace sync’ed page flipping.

I can see why you’d want to use a separate event thread. That allows
you to timestamp input events with arbitrary accuracy regardless of
the rendering frame rate. However, most of the time, if you need low
latency/high accuracy input handling, you also need a relatively high
frame rate for a usable end result.

I’d recommend doing everything (except sound, for various reasons) in
a single thread. It’s more robust, simpler, and tends to work well on
all platforms, including those that have threading issues or don’t
support threading at all.

It seems that it’s what SDL_WaitEvent does but I have read it
"samples" the input flow by waiting 10 ms between calls to
SDL_PollEvent. So I guess there is no way to wait exactly for the
amount of time separating two events, and which is not necessarily
a multiple of 10 ms.

That would depend on the underlying platform, at least in theory… On
most platforms, you can block properly when waiting for events, but
the problem is that on many of them, you can’t have a single thread
block on multiple different sources at once. (Traditional Un*x
problem.)

As a result of this, (AFAIK) SDL always polls for events every 10 ms.
IIRC, it does this no matter how the application reads events, so you
won’t get improved accuracy by polling from the application.