If I understand the spec correctly, in the case of keyframe effects, an UA is
expected to periodically update all keyframe effects. Upon being requested to
update itself, a keyframe effect then queries the animation (who in turn
queries the document timeline) to get time fraction and current ite
I think I understand it now.
What the reschedule step is really trying to do is to delay the pending task.
And it can be equivalently expressed as canceling the current pending task, and
then queue a new task doing what the original pending task was supposed to do.
So when you suggested it can
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
th
Hi,
We previously resolved[1] to add some extra methods to the Animation
interface. I've been going over this and I'm not sure how much we
actually need to change.
First, recall the states of an Animation which we can simplify to the
following three:
idle = no current time (*may* have a
