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

[Pierre Phaneuf]

On Thu, May 15, 2008 at 5:37 PM, Ryan C. Gordon <icculus at icculus.org> wrote:

>> 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? ;-)
>
> For what it's worth, in almost a decade of using SDL for high-end games,
> I've never had a problem with losing events, and if I did, it was probably a
> game bug, not an SDL bug.

The problem with high-end games is that they're usually coded at least
half-way properly (all relatively speaking, I've seen some awful
things too!), and they're usually not the type of games that clamp the
framerate, but go full tilt and just SDL_PollEvent() between each
frame. A high-end 3D game might be missing events if things fell down
on Mesa software rendering, but you'll have other problems beside
missing events anyway, you're not likely to notice. ;-)

I don't think I've ever lost events either, since my code was already
geared up to drive Linux/OSS sound from a single thread, but I suspect
those that do miss events are those using SDL_PushEvent() a lot,
possibly from other threads, say. The queue is what, 128 events, 256?
Something like that...

The fact is, the way it's designed, it has a limited capacity, and
once *something* fills it up, it's filled up for everything, including
things that weren't buggy otherwise.

> For what it's worth, you _could_ implement a system that makes SDL work more
> like what Windows is doing behind the scenes...it doesn't generate an event
> for every mouse motion, but rather sets a "the mouse has moved" flag when
> the hardware interrupt triggers, and generates the mouse motion event if
> this flag is set when you pump the queue, with a delta between the last
> mouse event and the current one...which guarantees the one thing that will
> definitely cause a queue overflow never can, at a probably imperceptible
> loss in precision.
>
> But frankly, I don't think this is a realistic problem in SDL, even on OSes
> that aren't making that tradeoff behind the scenes. The amount of lag
> between event queue pumps that you'd have to introduce means that lost
> events are the least of your problems.

Artificially pumping events from the system into SDL makes this worse
on those platforms, actually, because it turns what could be just one
event into a number of discrete events.

What is generally best is to keep the queueing you do to a minimum, if
you can. For example, you can keep an event queue, like we do now, but
only for SDL_PushEvent()-generated events, and if it's empty (or
alternatively, implementation details to be worked out), do a
PeekMessage or a XPending/XNextEvent, translate it, and hand it out,
as we get them in SDL itself, instead queueing them in, then out
immediately. There's a few details to avoid starvation in some
situations, but nothing too bad.

My idea is that this can leave the events-dropping to the system, and
just do it things straightforwardly in SDL itself (no queueing for
everything). I'm understand I might be a bit excessive, though, coming
from high-performance network server stuff, but I'd like to have as
much common code in my server as in my client, so that would be nice
to get right.

> Now the poll-sleep-poll-sleep problem we were discussing with
> SDL_WaitEvent() is worth fixing, since it'll eat battery life on embedded
> devices, where blocking forever in select() works better.

Yeah, that's one of the most important problems, I'd say (plus, I
think there's a tiny detail wrong in X11_Pending that can get it
starving in some rare circumstances, a one-liner fix kind of thing,
nothing too serious). The previous stuff sounds more like 1.3 fodder
to me, and I'd be interested in figuring it out properly, since that's
a rare occasion where the API compatibility is being broken.

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