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

[Ryan C. Gordon]

> 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.

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.

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.

--ryan.