Re: Modernizing the display loop [try 2]

[William Swanson <swansontec gmail com>]

On Mon, Dec 12, 2011 at 11:02 AM, Owen Taylor <otaylor 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