- From: Jan Linnebank <jan@linnebank.nl>
- Date: Thu, 25 Aug 2011 09:35:01 +0200
- 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