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 ;)
>
>
I've made this change in 458:4843fb42912f along with defining that the
callback's parameter is gathered by running the window.performance.now()
algorithm before any callbacks are invoked.  This means that one
script-observable side effect is that the parameter will always be <= the
value that script could observe by running window.performance.now() in the
callback, and it's not something like an expected presentation time that
may be in the future.

Can you confirm whether this is consistent with what you intend to ship in
IE10, Jatinder?  My understanding is that this is consistent with Mozilla
and Chrome's expected behavior.

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