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

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