- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 29 Feb 2012 12:30:11 -0500
- To: public-web-perf@w3.org
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 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. :( -Boris
Received on Wednesday, 29 February 2012 17:30:46 UTC