W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2011

Re: [RequestAnimationFrame] Changing callback timestamp parameter to submillisecond precision, monotonic clock, root navigation based

From: Jan Linnebank <jan@linnebank.nl>
Date: Thu, 25 Aug 2011 09:35:01 +0200
Message-ID: <4E55FB25.7040603@linnebank.nl>
To: public-web-perf@w3.org
Hello all,

Most people on this list only talk about 60 hz, while in practice and 
maybe in the future, different refresh-rates are encountered.
The HP laptop I'm working on at the moment, has by default a 59 hz 
refresh rate.
In the future different types of screens can be expected, maybe even 
with slightly lower refresh-rates (new types of eReader screens etc.).

Regards,

Jan Linnebank


On 25-8-2011 0:25, James Robinson wrote:
> I'd like to propose that we change the timestamp parameter to the 
> requestAnimationFrame callback to follow the same pattern as we've 
> decided to adopt for other timing mechanisms.  In particular, propose 
> the following changes:
>
> - define the time source to be the monotonic clock
> - define the time base to be the root document navigation instead of 
> the Unix epoch
> - change type from DOMTimeStamp (which is an integral type) to double 
> so we can represent numbers with better than millisecond precision
>
> We've run in to issues with precision and clock skew when doing local 
> testing, and I imagine that users in the wild will do the same.  Since 
> the expected use of the timestamp is to measure durations (for timing 
> out animation progress, etc) using a monotonic clock makes a lot more 
> sense than using something like Date.now() which is subject to system 
> clock adjustments and so on.  Additionally, having submillisecond 
> precision is important especially for tracking performance since 60Hz 
> does not map to an integer number of milliseconds.
>
> Note that there's another proposal to expose this timestamp to script 
> via window.performance.now(), which will allow authors to sync things 
> up to this clock even outside of rAF callbacks.  This is necessary to 
> achieve certain effects so we will probably want to implement this API 
> alongside changes to requestAnimationFrame, even if they aren't 
> defined in the same spec.
>
> If this sounds good to the working group I'm happy to make the 
> appropriate edits to the spec (although I'm on vacation for the next 
> week, so it may not be until early September that I'm actually able to 
> commit the changes).
>
> - James
Received on Thursday, 25 August 2011 07:35:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC