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 18:04:51 UTC