Re: Answers to some comments about frame synchronization

[Owen Taylor <otaylor redhat com>]

On Thu, 2013-02-14 at 15:35 -0500, Alexander Larsson wrote:

> > I haven't tested on anything but X11. My feeling is that we should
> > just
> > switch g_get_monotonic_time() to using QueryPerformanceCounter() on
> > windows, and not worry about all the warnings you find on the
> > internet
> > that on some old version of windows on some buggy bios that QPC jumps
> > as you switch between cores.
> >
> > If it turns out that doesn't work, we can write some function that
> > combines GetTickCount() and QPC and sanity-checks, interpolates, etc,
> > but we really shouldn't do so without having demonstrated existence
> > of
> > such buggy systems among our user base.
>
> I did a bunch of research on this, see the g_get_monitonic_time() win32
> implementation for it. I definately don't think we can just rely on QPC
> as is. Its not monotonic, it will drift over time and i believe over e.g.
> cpu sleeps. If we use it we should slave it to the lower precision clock
> in some kind of PLL (this is what firefox does). I just couldn't be
> bothered with the complexity last time...

The Firefox bug linked to from the GLib comments is 5 years old, and
in following through to various links, all the problems people were
describing were with Windows XP. I'm not convinced that this is a
current problem. DwmGetCompositionTimingInfo() which is the primary
interface we might want to interact with uses QPC time, so my impression
is that Microsoft's view of QPC is that it gives you sane timestamps
along the lines of CLOCK_MONOTONIC on Linux, and not uninterpreted rdtsc
values.

> And anyway, the QPC time is just for reporting time. A poll() sleep (i.e.
> MsgWaitForMultipleObjectsEx) will still use the timeGetTime precision, so
> it does not help here.

True. One thing we may want to do on Windows is consider having
gdk_paint_clock_get_frame_time() return a nominal time that increases by
1/60fps at each frame rather than using g_get_monotonic_time(). That
will cover up some amount of timing skew, since we know that frames go
*out* at regular intervals.

This has to be done somewhat carefully - if you can only do 40fps, then
you *want* frame times that increase by 1/40fps instead of quantizing to
the frame rate.

In terms of using timeBeginPeriod() and timeEndPeriod(), unfortunately,
the GDK level API has no concept of a "running animation", so it's not
clear when GDK would set up a period. We could add such a thing -
basically gdk_frame_clock_begin_continual_updates() - which would help
for style animations and gtk_widget_add_tick_count(). It wouldn't help
if a higher level built on top of GTK+ has an interface like
window.requestAnimationFrame() or we're reacting to mouse events.

- Owen