Re: [web-animations] does rescheduling create pending task?

On 2015/04/11 15:48, Glen Huang wrote:
> Hi Brian,
>
> Thanks for the explanation.
>
> The explanation is perfectly clear, but I'm unable to relate it to the
> requirement "reschedule that task to run as soon as animation is ready".
> This doesn't seem to have anything to do with delaying the resolving of
> the ready promise.
>
> To me it sounds like this: the animation has a pending pause/play task,
> now you set a new effect to it, you should wait until the new effect's
> first frame is rendered and then run the task.

Yes, that's right.

> So I'm a bit confused when you said it should be better expressed as
> canceling it. Maybe I misunderstood the meaning of rescheduling?

If the task that resolves the promise etc. is scheduled in a queue and 
the effect is changed, that task should be cancelled (i.e. removed from 
the queue) and a new task scheduled once the new first frame has been 
rendered. Does that make more sense?

>> What do you mean by effect1 being updated?
>
> I was initially under the impression that running a pending task would
> cause css properties specified in effect1 to be applied to its target.
> Now I realize that's wrong, the pending task only updates the animation
> object. I will ask a different question:
>
> The code example is meant to simulate the rescheduling scenario I had in
> mind: The animation associated with effect1 is played, but it isn't
> associated with a timeline, so it has a pending play task. Now the users
> replace effect1 with effect2, triggering the reschedule step. After the
> animation has been associated with a timeline, it should be considered
> ready, At this time, should the pending play task created when animation
> was associated effect 1 be run to update the animation object?

I'm still not sure what you mean by update the animation object.

Looking at the code we have:

>>
>>     ```js
>>     let effect1 = new KeyframeEffect(…);
>>     let effect2 = new KeyframeEffect(…);
>>     let anim = new Animation(effect1);

anim's start time and current time are both null.

>>     anim.play();

anim's hold time gets set to zero. effect1's computed timing will 
reflect this time.

The ready task won't run, however, until anim has an active timeline.[1]

>>     anim.effect = effect2;

The reschedule step happens (but the ready task was never going to run 
anyway without an active timeline). effect1 is no longer in effect. 
effect2's computed timing now reflects the time inherited from anim.

(If we were to paint at this point, we'd apply the properties defined in 
effect2.)

>>     anim.timeline = document.timeline;

We now have an active timeline but we still haven't satisfied all the 
conditions for being ready.[1] We still need to wait for any setup to 
complete such as painting the first frame of the animation.

Sometime later (typically within the same frame, but not necessarily) 
the animation will become ready and the ready task will be run which 
will resolve the ready promise etc.

Does that make more sense?

Best regards,

Brian


[1] http://w3c.github.io/web-animations/#ready

Received on Tuesday, 14 April 2015 07:59:46 UTC