Re: [css-animations][css-transitions] What is the intended use of elapsedTime?

Hi Tab,

Thanks for getting back to me!

On 2015/10/01 6:29, Tab Atkins Jr. wrote:
> On Wed, Sep 30, 2015 at 1:14 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
>> What is the purpose of the elapsedTime member on TransitionEvent and
>> AnimationEvent. Are there specific use cases for it?
>
> I presume that it's for the purpose of syncing up JS-driven things
> with CSS-driven animations.

That seems to contradict the idea that it's frame-rate independent, 
right? If the time reported is the ideal time, not the actual progress, 
then you can't use it for syncing things up, right?

For example, if I have an animation of duration 3s that repeats twice, 
and I get a frame after 3.1s, and I generate an animationiteration event 
with elapsedTime 3s then I think that doesn't help you sync up with the 
animation's actual progress.

>> For example, if an animation runs for 3s and the first frame after
>> the animation ends occurs at 3.1s, does elapsedTime on animationend
>> report 3 or 3.1?
>
> animationedend should report 3, definitely.  That's when it ended.
> That's a different issue than events firing *during* an animation.

I'm not sure what that means. Are you suggesting the behavior is 
different for animationiteration? Or animationstart?

>> We could go a couple of different ways here:
>>
>> A. elapsedTime represents the animation time if the animation was
>>     sampled at an infinitely fast rate (i.e. 3).
>>
>>     This approach provides consistent values regardless of the
>>     performance of the underlying system. However, it opens up all sorts
>>     of other questions:
>>
>>     1. If the magnitude of negative delay is greater than the animation
>>        duration, do we clamp the elapsedTime to the duration?
>
> Delay and duration don't have anything to do with each other.  Am I
> missing something from this question?

In this case, the animation finishes before it starts. As the spec 
currently reads, you'll get an animationstart with an elapsedTime of 
-delay and an animationend of duration. e.g.

   animationstart, elapsedTime: 4
   animationend, elapsedTime: 3

>>     2. If the author seeks backwards past the beginning of an animation
>>        with a negative delay and then plays forwards, presumably the
>>        animation starts from its natural beginning and dispatches an
>>        animationstart event at that time with elapsedTime = 0.
>>        Doing that, however, feels like saying the elapsedTime depends on
>>        when the animation is sampled which seems at odds with this
>>        approach.
>
> I'm not sure I understand.  In the case of a normal negative-delay
> animation, we can't actually go back in time to fire the
> animationstart event, so we fire it at soon as we start applying the
> animation, and let you know that this "start" actually began a certain
> distance into the animation.  (start is the only thing that's weird
> like this, because we guarantee it's fired even if you never
> experience the "start" moment of the animation.  Other events only
> fire if you actually play through their associated moment.)

With developer tools or the Web Animations API we can go back in time to 
fire the animationstart event a second time. On that second time around, 
we'd presumably use an elapsedTime of zero.

So in effect I think we end up with a flag indicating that we seeked 
into the animation when we started it and hence we need to adjust the 
elapsedTime based on that seek time.

>> B. elapsedTime represents the difference between the current frame time
>>     and the start time of the animation (i.e. 3.1).
>>
>>     This is more simple but I wonder if it is useful.
>>     If you're running on a slow device you'll get completely different
>>     times. The animationstart event might fire after the animation has
>>     finished and the elapsedTime might be greater than the animation
>>     duration. In that case, I don't know what it is used for.
>
> No, this is wrong.  Any event which has a defined moment to occur at
> (iteration events, etc) needs to report that time, because that's when
> they were queued (in the absence of a slow main thread).

I think this approach is actually more useful if elapsedTime is to be 
used for synchronizing since it tells you the actual progress of 
animations at the current frame. That said, I don't think that's what 
the spec intends.

Best regards,

Brian

Received on Thursday, 1 October 2015 01:36:47 UTC