>> And, indeed, on platforms which /do/ support threads, the
> actual semantics
> are left unchanged: SDL_WaitEvent() will return faster once
> an event is
> available and not hog (part of) the CPU while it waits, but
> will otherwise
> act exactly as it always had.
this is a change that i, for one, (for what its worth) would like to
see in SDL. is there somewhere other than this list that one can
watch to determine which patches have been accepted?
> The only other change (not dropping events when the queue is full) is
> arguably a bugfix. I wouldn't expect any library user is legitimately
> relying on events being lost. :-)
and argue i shall ;) well, perhaps not argue so much as clear my own
misunderstandings of how SDL works...
while i agree that no user should be relying on events being lost when
the queue is full, i think its a good way to handle a bad situation.
it is, to me, the least error-prone way of handling such a situation.
are there not consequences to blocking the event delivery thread?
won't this result in the application appearing unresponsive to the OS?
assuming SDL handles certain events before putting them on the queue
(like redrawing when focus is gained), the application may continue to
appear to be OK and be given a chance to recover. if the queue filled
up because of a temporary processing blip, then this may be desirable.
just thinking out loud...
.marc