Re: Specifying window.performance.now()

On Wed, Feb 29, 2012 at 1:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/29/12 4:20 PM, James Robinson wrote:
>
>> I'm a little more optimistic about requestAnimationFrame.  It's true
>> that lots of code is using JS Date.now(), but that code will continue to
>> work as-is.  I do not think that there is a large amount of web content
>> out there using the callback _parameter_ for timing, most code is just
>> ignoring it and grabbing the time out-of-band.
>>
>
> If true, that would make things work ok.  I guess I'd thought people would
> actually use the parameter, since it's there for a reason...
>
> Certainly the demos I've seen using requestAnimationFrame use it.  I seem
> to recall Google Maps doing so too, but maybe they changed that?


Technically speaking using the parameter to track animation progress is OK,
so long as the page isn't trying to compare the parameter to JS Date.now()s.

My reading of the code that Google Maps is using for animations today is
that it's always using the value of Date.now() to update its internal
progress.  I could be wrong since I'm only reading the code and not testing
it, but I believe that we're OK for that site in particular (and anything
else using this particular bit of common Google JS infrastructure for
animations).

- James


>
>
>  I think we should try changing this and see what happens.  If it turns
>> out that we can't change the value of the first parameter to the
>> callback, then we can do something uglier like provide a second callback
>> parameter.
>>
>
> :(
>
>
>  I think that we definitely do want to provide a timestamp to
>> authors as a callback parameter so that they can synchronize multiple
>> animations running on the same logical frame.
>>
>
> Oh, we absolutely do.  That's what Gecko does right now.  The only
> question is what the timestamp's 0-point should be....
>
> -Boris
>
>