Re: Specifying window.performance.now()

On Wed, Feb 29, 2012 at 9:30 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/29/12 9:26 AM, Jonas Sicking wrote:
>
>> The main application of Performance.now seems to be relative timing,
>>> which doesn't particularly require any origin. It seems to me to be a bit
>>> easier to allow an arbitrary origin, so that the implementation doesn't
>>> have to track a zero time and subtract. Do some important applications
>>> require zero to be start of navigation?
>>>
>>
>> It might be interesting to align with requestAnimationFrame. It
>> currently uses Jan 1st 1970 as 0 time though there's a note that that
>> might change. See step 2 in
>> http://dvcs.w3.org/hg/webperf/**raw-file/tip/specs/**
>> RequestAnimationFrame/**Overview.html#processingmodel<http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#processingmodel>
>>
>
> I would love that, but...
>
> While Gecko provided a way to get an opaque time stamp that could be
> compared to (and subtracted from to get milliseconds) the
> requestAnimationFrame timestamps, other implementors did not.  As a result
> content using requestAnimationFrame commonly uses JS Date() objects to
> record the start of the animation or whatever other time the argument to
> the animation frame callback is compared to.  It simply had no other option.
>
> And since that content commonly uses the unprefixed form of
> requestAnimationFrame if that's available to be "future proof", it's not
> like prefixes are saving us here.
>
> In addition to that, converting existing scripts that use
> setTimeout/setInterval to the new API is made easier if the script-visible
> timescale roughly matches JS Date().  This might have been OK to forgo, I
> guess, but it's what motivated the original implementation in Gecko as an
> offset from the Unix epoch.  In retrospect, maybe it would have been better
> to not do that and use an arbitrary origin, thus forcing people to
> implement a parallel "what time is it now?" method.
>
> In any case, I somewhat doubt requestAnimationFrame could change here. Too
> much web content is depending on those times being comparable to JS Date
> simply because it had no other choice.  :(


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.

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.

- James


>
> -Boris
>
>