Re: Temporary removal of animations

The cancel() behavior is a bug, we're tracking it here:
https://code.google.com/p/chromium/issues/detail?id=434529. Thanks for
finding it!

The promises have a rather specialized purpose, not related to style. The
web platform already deals with the fact that style changes don't
necessarily apply immediately; but animations provide a new problem:
animation timing state can be dependent on an asynchronous resolution of
animation commands.

For a concrete example, imagine an animation is playing off-main-thread
(opacity and transform animations do this on all browsers now, I believe).
If that animation is paused, then the paused current time needs to be
fetched from the animation thread, otherwise it could be wrong (e.g.
multiple frames may have been generated between issuing the pause command
and that pause taking effect). The promise both models this and provides a
concrete way to determine when the current time has resolved correctly.

In contrast, when the currentTime is set, this immediately resolves the
animation state to a known correct set of values. Hence no promise is
needed to delay resolution.

Cheers,
    -Shane



On Wed Nov 19 2014 at 8:24:05 AM Jonathan Moore <moore@eds.org> wrote:

>
> On Tue, Nov 18, 2014 at 12:39 PM, Shane Stephens <shans@google.com> wrote:
>
>> I think this issue points to a bug in the Chrome implementation. Even
>> though cancel is asynchronous, from the perspective of the main thread its
>> effect on style should be immediate (or at least appear to be - calling
>> cancel should invalidate the style of the element the animation is
>> targeting). After all, the animation itself is observable as cancelled -
>> its playState switches immediately to 'idle'. I'd like to talk it over with
>> some people on my team but assuming they agree I'll file a bug on our impl.
>>
>
> As I mentioned, setting the currentTime makes changes visible
> immediately.  So setting the currentTime past the end has the effect I
> want. Infact setting player.currentTime = player.currentTime forces the
> recalc style for the cancel() case. I have attached a version of my test
> case that shows these behaviours.
>
> One question I have is what happens if I set currentTime to past the end,
> then back to where it was. ie for a player with duration 1000:
>
>   var current = player.currentTime ;
>   player.currentTime = 1000000000000;
>   player.currentTime = current ;
>
> The spec seems to indicate that promises should be resolved at the time I
> set the currentTime passed the end:
>
>   http://w3c.github.io/web-animations/#set-the-current-time
>
> This seems wrong to me.
>
>