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

[Forrest Voight]

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
>