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

[Edward Cullen]

Hi,

Must confess, I'm not in a position to comment on the detail of what 
you've written; I was simply trying to give you what I know as an 
overview...

I think you'll need to take this up with Sam and/or Ryan directly, as 
they're MUCH more familiar with the internals and design decisions with 
regard to various platforms than I probably ever will :).

Sam is normally very open to ideas (especially those accompanied by 
sample implementations...), but he has also spent a very long time 
refining SDL, so don't be surprised if he has 'answers for everything'. 
  It may be that some original assumptions no longer apply - SDL started 
back in 1998ish... :D

Eddy

Pierre Phaneuf wrote:
> On Fri, May 9, 2008 at 5:01 AM, Eddy Cullen <eac203 at ecs.soton.ac.uk> wrote:
> 
>>  From what I understand, one of the design decisions made, was to provide
>> consistent behaviour across platforms. Due to restrictions on OS
>> locking/threading semantics on some operating systems, SDL implements
>> busy-waiting, even on platforms that support interaction with the scheduler.
> 
> There's some stuff that is *really* hard to get consistent semantics
> right across multiple platforms. But this particular API
> (SDL_WaitEvent) is quite simple: wait until the next event, as quietly
> as possible. You could achieve that with an extra method in the video
> driver dispatch table, and if it is NULL, fall back to the current
> method of looping with the delay, it would only be better.
> 
> Note that this involves no interaction with the scheduler, just using
> the platform API the most common way. On most platforms, there is a
> blocking "wait for the next event" call (XNextEvent, GetMessage,
> PhNextEvent, etc), which fits in quite naturally, and in most cases,
> they also allow fitting that with waiting for other things
> (ConnectionNumber with select, WaitForMultipleObject, PhEventArm and
> PhEventRead). It isn't surprising and is quite natural, since that's
> how most hardware in the last 20 years works (interrupt-driven).
> 
> Also, note that SDL_WaitEvent didn't really do real busy waiting, but
> rather does "arbitrary waiting". This is better than busy waiting for
> CPU usage (although worse than my approach), but mainly has terrible
> latency effects. As for interactions with locking/threading semantics,
> hardly any platforms have threads as a first class citizen, BeOS and
> Java being exceptions, and from what I can see, that wasn't the best
> idea ever (the best thing is to use a mix of threads and state
> machines, with a low number of threads, too many threads leading to
> excessive context switching, which Java finally found out and
> addressed with NIO, at some point, and BeOS died before they could).
> 
>>  Possibly, the key issue is whether this decision should stand - perhaps
>> additional APIs are required?
> 
> I'd just propose improving SDL_WaitEvent internally, with the exact
> same semantics that it has currently, without big changes in
> architecture (if I could do most of it from outside of SDL in my test
> program, it's obviously not too far).
> 
> I'm also not too thrilled by the excessive reliance on the event
> queue, which has some poor characteristics. On most platform, SDL
> could get events directly from the platform, without any queueing, and
> it would reduce the "losing events" effect (either platforms will be
> sensible and not lose events, or they will lose them, and we'll be in
> the same place as today), while letting proper event flow control work
> (SDL_PumpEvents can lead an underlying event system to believe that an
> SDL application is processing events quickly, when in fact SDL are
> throwing them out as fast as possible, which is a loss of information,
> leading to bad decisions on the part of the platform, in this case,
> sending even more events!). We still need the event queue for
> internally generated events (SDL_PushEvent), and when getting an
> event, SDL would first look at the queue, and if it is empty, ask the
> platform (possibly in a blocking way, if it is in SDL_WaitEvent).
> 
>>  As I write this, it all feels horribly familiar, like it's already been
>> discussed on the group...
> 
> I'd be very interested in pointers as to that, actually. Often, there
> is a reason for why things are in some way. I actually have rather
> specific rules for whining and flaming (documented here:
> http://www.advogato.org/person/pphaneuf/diary/118.html). In this
> particular case, there is a tricky bit: I have personally done it (or
> at least helped out doing it) better on Svgalib, X11 and Win32 (I
> suspect it's possible on Mac OS "classic", since they're not exactly
> thread-friendly in general). The documentation for Photon seems to
> point that it is in fact designed for exactly this (QNX is often close
> to the hardware, so it's not surprising).
> 
> But there's other platforms supported by SDL that might have different
> restrictions that I do not know about. As I said, I'm still going with
> at least category B ("whining is allowed if you can figure out a
> better way"), and it'd be surprising if I was wrong, considering the
> state of hardware in general, but there are some weird things out
> there (*eyes WinCE suspiciously*)...
> 
> So I'm quite keen on finding out more about those other odd platforms. :-)
>