W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2012

requestAnimationFrame time and DOMHighResTimestamp

From: Nat Duca <nduca@chromium.org>
Date: Wed, 9 May 2012 11:04:17 -0700
Message-ID: <CAAMsTOvyepDGfWLGStXikEn73qndzgPYAeFrPFDXXjYJwevqVw@mail.gmail.com>
To: public-web-perf@w3.org
A while back, JamesR and I volunteered to try out changing
requestAnimationFrame's "time" argument to use DOMHighResTimestamp
instead of DOMTimeStamp. I think a report on our initial findings is
in order :)

The bug where we did this work was here:

We ended up having to revert this patch after about a week due to
branch point pressures. Here's what was broken when "the real world"

* Closure library animation broke (thus lots of Google properties broke)
* Erik's "robust polyfill"
reposted here, http://paulirish.com/2011/requestanimationframe-for-smart-animating/).
We're not clear how widely used this snippet is.

The key issue that crops is animation libraries that use this design pattern:

function MyAnimation(duration) {
   this.startTime = Date.now();
   this.duration = duration;
MyAnimation.prototype.tick = function(time) {
   if (time > now) {

An edit to fix this is pretty easy... switch the startTime to use

The problem is that its not possible to polyfill: there's no way to
"feature detect" whether the browser is passing HighRes time to you
versus DOMTimeStamp. They're both Number.

I dont have a strong opinion on what to do next. We've talked
informally about 2nd-argument, or putting something on window to help
write polyfills for this case. If we had a polyfill, we might be able
to try again --- even though a few things broke, given a good
polyfill, the number of raf-based animation systems seemed
small-enough to be still-within the scope of an outreach effort.

What do folks here think?

- Nat
Received on Wednesday, 9 May 2012 18:04:51 UTC

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