Re: Semantics of the time argument on rAF's FrameRequestCallback

On 5/9/12 6:23 PM, Nat Duca wrote:
> function Animation(duration) {
>     this.startTime =;

First bug here.  The right thing to set startTime to in this situation 
is the time of the last refresh tick, not now()....

>        assert( - a.startTime>= a.duration);

If startTime were not tied to now() (which it shouldn't be), this assert 
would be completely nonsensical....

>     var a= new Animation(1000.0);
>     a.addEventListener('animationEnded', function() {
>        assert( - a.startTime>= a.duration);
>        aEnded = true;
>        checkBothEnded();
>     });
>     var b= new Animation(1000.0);
>     b.addEventListener('animationEnded', function() {
>        assert( - b.startTime>= b.duration);
>        bEnded = true;
>        checkBothEnded();
>     });
>     checkBothEnded() {
>       if (!checkTaskEnqueued) window.postTask(checkBothEnded);
>       assert (aEnded&&  bEnded);
>     }

As written, this will always fail the assert in checkBothEnded, so I 
assume you meant something different from what you wrote.  Not sure 
what, though.

> I think that this is why most animation systems pass a frame begin
> time as well as a present time.

So in terms of rAF, "present time" would be the animation sample time 
and "frame begin time" would be the time it was before all the code for 
this frame started running?

How would having both help the use cases here?

> (CVDisplayLink is documented here, though it doesn't explain the
> rationale for the design:

This looks like it's passing in an "inOutputTime" which is the animation 
sample time and the "inNow" which is .. not really all that 
well-defined.  Is the same for different output callbacks, or does it 


Received on Wednesday, 9 May 2012 23:43:14 UTC