On Mon, Dec 12, 2011 at 11:02 AM, Owen Taylor <otay...@redhat.com> wrote: > The other thing we might want to do here is add in the ability to > get the time for a clock - say: > > guint64 gdk_window_clock_get_time() > > which would return a monotonically increasing time for the clock > (in microseconds?)
This is a good idea, but consider how it would be used. Most UI animations have a definite beginning time and a brief duration: /* When the animation starts: */ start_time = gdk_window_clock_get_time() /* Once per frame: */ animation_time = gdk_window_clock_get_time() - start_time This is slightly inconvenient, since it involves querying the time at the start of the animation and dealing with wrap-around issues in the subtraction (using guint64 is certainly one solution). Now, consider how this would work if the API provided time _differences_ between frames, rather than a monotonic global time: /* When the animation starts: */ animation_time = 0 /* Once per frame: */ animation_time += gdk_window_clock_ frame_duration() This is somewhat simpler. In fact, it might even make sense to provide the frame duration as a parameter to the update() callback, since that's where it is most likely to be used. I realize this is a minor point, but accumulating time differences always seems to come out cleaner in my experience writing animation code. Some things like particle systems don't even need to maintain an animation_time, since they can use the frame duration directly. Absolute time is really only useful when syncing with media playback, but streaming API's have their own timers for that. -William Swanson _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list