Re: requestAnimationFrame time and DOMHighResTimestamp

On Wed, May 9, 2012 at 12:28 PM, Jatinder Mann <jmann@microsoft.com> wrote:

> 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 for this data.  I think based on this and what we've experienced we
should change the parameter to DOMHighResTimeStamp and try to evangelize
sites that depend on comparing to Date.now() to be aware of this change.
 I'll make the edit to the spec and we will try to make this change again
in Chromium and update the WG if we run into any hard blockers.

- James


> 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
>
>
>
>
>
>
>
>