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

[René Dudfield]

ah nice one.

I guess you could make a post event with this wait function that first
posts something to the sdl event queue, then post a noop X event... so
that your program wakes up to process the event.

cu,



On Fri, May 16, 2008 at 9:59 AM, Forrest Voight <voights at gmail.com> wrote:
> I agree that having something like select() would be more useful.
>
> Here's a PyGame snippet that does this (only on x11):
>
> import pygame
> import ctypes
> import select
>
> def get_fd():
>    w = pygame.display.get_wm_info()
>    w = w['display']
>    n = int(str(w)[23:-1], 16)
>    n = ctypes.cast(n+8, ctypes.POINTER(ctypes.c_int)).contents.value
>    n = ctypes.cast(n+8, ctypes.POINTER(ctypes.c_int)).contents.value
>    return n
>
> def wait(fd, timeout=None):
>    select.select([fd], [], [], timeout)
>
> Also, I think removing SDL_PushEvent() would solve a lot of
> problems... including simplifying event blocking when it is
> implemented. It doesn't make sense to use an outside library to manage
> a game's event queue to me...
>
> Cheers,
> Forrest Voight
>
> On Thu, May 15, 2008 at 6:16 PM, Pierre Phaneuf <pphaneuf at gmail.com> wrote:
>> 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/
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>