RE: requestAnimationFrame time and DOMHighResTimestamp

Internally, we have updated our requestAnimationFrame implementation to use DOMHighResTimeStamp and are planning to ship IE10 this way. As a part of this change, we ran compatibility tests on the top million or so websites and only found three sites that were broken by this change. All of those site were easily fixable with a simple change to use performance.now(). 

I think it will be quite manageable for the few sites that are dependent on this behavior to update their code. I don't think sites will need to "feature detect" whether a browser supports DOMHighResTimeStamp or DOMTimeStamp in this scenario; for interoperability's sake, the spec needs to choose one time value and all browser vendors need to align with that time value. Considering the benefits of a monotonically increasing, sub-millisecond time, I think it's clear we should stick with DOMHighResTimeStamp. 

If "feature detection" is needed for the short term, checking for performance.now() may help. Also, if a browser supports DOMHighResTimeStamp for rAF time, it won't be a 13 digit number ;)

Thanks,
Jatinder

-----Original Message-----
From: nduca@google.com [mailto:nduca@google.com] On Behalf Of Nat Duca
Sent: Wednesday, May 9, 2012 11:04 AM
To: public-web-perf@w3.org
Subject: requestAnimationFrame time and DOMHighResTimestamp

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:
https://bugs.webkit.org/show_bug.cgi?id=77229

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"
interefered:

* Closure library animation broke (thus lots of Google properties broke)
* Erik's "robust polyfill"
(http://my.opera.com/emoller/blog/2011/12/20/requestanimationframe-for-smart-er-animating,
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;
   requestAnimFrame(this.tick.bind(this));
}
MyAnimation.prototype.tick = function(time) {
   if (time > now) {
     this.dispatchEvent("ended");
     return;
   }
    ...
  requestAnimFrame(this.tick.bind(this));
}

An edit to fix this is pretty easy... switch the startTime to use window.performance.now().

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 19:30:54 UTC