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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
