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

On 5/9/12 8:39 PM, Nat Duca wrote:
> What do you set it to when you've been idle for a while? The last tick
> may be many seconds ago.

What Gecko's mozAnimationStartTime does is the following:

1)  If there is no active animation timer, start one and set the "last
     tick" time to now.
2)  Return the "last tick" time.

And of course every tick sets the "last tick" time to the time when it 
happened.

> So, I still claim that this is correct.

It's "correct" only if your animation doesn't need to coordinate its 
start with other animations.  If you want to start several animations, 
then setting each one's startTime based on the now() value when running 
its start code will put them slightly out of sync with each other.

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

I must still be missing something here...

> The point is, if you use window.performance.now() to determine whether
> an animation ended, and you have two animations that are ending at
> exactly the same time, and the tick happens right on that boundary,
> you can get one animation that ended and one animation that didn't
> end.

Yes, agreed....  That's because using window.performance.now() for 
_anything_ like boundary determination that way you will get screwed. 
If you use it for a _single_ animation it can fail in the same way if 
you happen to call now() twice!

>> 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?
>
> Sorry, I wasn't precise about definitions. In my notes, "present time"
> uses the directx term for Present. That was stupid --- present meant
> the time that the content will be visible to the user.

Oh!  Stress on _second_ syllable, not first syllable!  That makes a 
rather large difference.  ;)

>> 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 increment?
>
> inNow goes up every frame, and is very close to the current system time.
> inOutputTime is the time that that any rendered content is going to be
> visible to the user.

OK.  But for a single frame inNow is the same for all callbacks 
triggered for that frame, right?

It sounds like inNow is basically what Gecko passes in right now, and 
inOutputTime is what we'd like to pass in...  Maybe it does make sense 
to pass in both.

-Boris

Received on Thursday, 10 May 2012 01:11:25 UTC