Re: Standardizing animationStartTime (was RE: [minutes] 2012-10-10 Web Performance WG Teleconference #84)

I don't think this API makes sense and don't intend to implement it in
WebKit (nor would I be able to even if I wanted to).  There are several
issues with it.  The basic issue is it is assumes (or tries to impose) the
notion that there is a defined start time for CSS transitions/animations,
when in fact there isn't.  CSS transitions/animations start time is not
defined by any standard and in general isn't known while script is
executing - we only know when an animation started after it actually has.
 There are a few reasons for this.

In WebKit, we always try to start animations at a time such that the user
can see the entire transition/animation.  For instance, if a transition is
supposed to update a value from 0 to 100 with a linear easing over 5 frames
the user should see frames produced with values of 0 (i.e. before the
transition starts), 20, 40, 60, and 100.  This means that we can't
determine the start time until we're ready to actually produce the first
frame.  If script is running, the browser can't predict when this time will
be.  In many cases we offload the process of running the
transition/animation to a dedication animation system that runs on a
separate thread.  When this is happening, the browsing engine doesn't have
any way to query when the animation will start other than to wait for a
notification to arrive after the fact with a start time.

Less significantly, having an attribute that updates is bad API design.
 This should be a function or a parameter to a callback to make it clearer
that it's an instantaneous value that will change over time.

Backing up from the proposal to examine the use cases, it seems that they
fall into a few buckets.  One is to be able to synchronize multiple
script-driven things.  That's already handled by the 'now' parameter to the
requestAnimationFrame callback which will be the same for all callbacks run
in one invocation of the "sample all animations" algorithm.  A second is to
synchronize script with SVG/CSS animations.  Since the start time of these
animations are not currently defined by any specification, that isn't
possible without changes to these animation systems today.  I believe the
Web Animation work allows script to explicitly set when an animation is
considered started which takes care of this.  The last is to get an
estimate of when the results of the currently executing script should
appear on screen to provide better synchronization with audio, input,
network, and other external data sources.  I think the proper way to
address this is to provide some sort of estimated vsync time as a parameter
to the requestAnimationFrame callback.  This has to be a guess (unless
someone's figured out how to predict the future in a browsing engine) but
will be useful.

- James


On Wed, Dec 5, 2012 at 12:36 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Dec 6, 2012 at 8:56 AM, Jatinder Mann <jmann@microsoft.com> wrote:
>
>>  Considering Firefox has supported a prefixed
>> windows.mozAnimationStartTime since Firefox 4, I would like to hear
>> Robert's take on whether we should standardize this attribute as well.
>>
>
> I think we should! We generally try to avoid exposing features that we
> don't think should ever be standardized.
>
> There is the issue that scripted animations can't stay in sync with
> animations offloaded to a compositor thread, even if we provide this
> attribute. I think that's OK. As long as there are animations that aren't
> offloaded to a compositor thread, which is very likely to remain true
> indefinitely for the current generation of browser engines, this attribute
> is useful.
>
> Rob
> --
> Jesus called them together and said, “You know that the rulers of the
> Gentiles lord it over them, and their high officials exercise authority
> over them. Not so with you. Instead, whoever wants to become great among
> you must be your servant, and whoever wants to be first must be your
> slave — just as the Son of Man did not come to be served, but to serve,
> and to give his life as a ransom for many.” [Matthew 20:25-28]
>
>