Re: Answers to some comments about frame synchronization

[Alexander Larsson <alexl redhat com>]

On tor, 2013-02-14 at 16:18 -0500, Owen Taylor wrote:
> On Thu, 2013-02-14 at 15:35 -0500, Alexander Larsson wrote:

> > 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.

That might be true, although we still support XP. All the official MS
docs on this are really unclear though, which is kinda strange.

http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx seems to
have some details though. It talks a bout timer coalescing too, which we
should perhaps make the g_timeout_add_seconds calls use.

> > 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.

Yeah, it seems risky wrt fps changing over time.

> 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.

We could add such an api though. For instance, we could have a
refcounted api on the paint clock like gdk_paint_clock_use/unuse() such
that any running animations would cause a clock use and thus higher
timing resolution on win32.