[SDL] sleeping better for lower latencies (and other things)

[Pierre Phaneuf]

On Tue, May 13, 2008 at 11:28 AM, Bob Pendleton <bob at pendleton.com> wrote:

> Here's the thing; you can lose events in SDL, but you don't. It is very
> difficult to actually lose events because it can only happen when your code
> is running to slow to be useful. One other point, it is possible to lose
> events on all platforms. Yes, the probability of losing events is very low,
> but any system with finite memory can lose events. Many device handlers for
> verbose devices such as mice and tablets are written to merge events (i.e.
> throw them away) just to prevent the software from having to handle so many
> events.

I've been the type to do sound processing (on Linux) without using a
separate thread, so coming back to the main loop in time is something
I've more or less HAD TO master, so I haven't been losing messages too
much (I was just using this as an example). :-)

I used that particular thing because I saw a lot of stuff referring to
it, like comments in the form of "now we won't lose events,
hopefully!", or the whole event thread thing (so that you can have a
thread picking up events and overflowing the SDL queue as fast as
possible?!?). It's not entirely correct to say that you can always
lose events, because some are "level" rather than "edge" triggered.
select() is a good example of this: it's an event delivery mechanism
that cannot possibly overrun (of course, the socket themselves could,
but that's another subject). But in any case, that's okay if some
(most?) events *could* be lost, what I'm saying is that we shouldn't
be introducing a mechanism where ALL events are now put to the lowest
common denominator: ANY event can now be lost! Equality for all, or
something? ;-)

Also, there is flow control issues to fully pumping the event queue
whenever we have the chance, like SDL does: it gives false signals to
event sources, saying that they can send more, which doesn't help if
we start drowning in events.

> Look at my stuff, I think you will like it. A lot of people use it to reduce
> latency and increase reliability on Linux and Windows. I have reports of it
> working on the Mac as well.

I've read its code, actually. Since it uses just about only SDL
functions, it should indeed work just fine on a Mac (and other
plaforms with SDL threading support). It cannot push events from the
same thread that gets them, obviously, but that is kind of a normal
thing to deadlock on (and that's why separating a "there's something
to look at" event from the thing to look at can be useful, for
removing that deadlock). I'm very annoyed at things like the
timerCallback, because that's just a band-aid to work around missing
functionality, and I was here just wishing for that functionality.
Hiding the hack inside a library doesn't make me any happier,
unfortunately.

Sometimes, I wish SDL/X11 was based on libXt rather than libX11 (see
XtAppAddTimeOut and XtAppAddInput, which are *exactly* what I want,
straight from the mid-80's). ;-)

-- 
http://pphaneuf.livejournal.com/