Re: Answers to some comments about frame synchronization

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

That might be true, although we still support XP. All the official MS
docs on this are really unclear though, which is kinda strange. 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. 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]