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

Re: requestAnimationFrame time and DOMHighResTimestamp

From: James Robinson <jamesr@google.com>
Date: Mon, 14 May 2012 15:04:45 -0700
Message-ID: <CAD73md+HjuZdNRkWdDeb4Mf=M-DnqE_q9x1z4Pak=cKcojy2pg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-web-perf@w3.org
On Mon, May 14, 2012 at 11:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/10/12 5:47 PM, James Robinson wrote:
>> 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.
> I've finally had a chance to read over the result, and it has some
> problems:
> 1)  Step 1 of section 5 doesn't define which window's performance.now()
> should be used.  As far as I can tell, the value of performance.now()
> differs in different windows, because the value of performance.timing.**navigationStart
> differs in different windows.  Note that this also means that using
> performance.now() in any sort of cross-frame scripting situation is a
> footgun, by the way.  I'll raise this as a separate issue

Yes this is broken :(.  I think the best thing to do is to fetch the
window.performance.now() for each document in the list and then pass that
to each callback, which would then punt the question of what the timebase
is to the definition of window.performance.now() in each document.  The
browser could (and I hope will) optimize this to only grab the clock once
and then apply appropriate offsets.  Let's discuss the
window.performance.now() behavior on its own thread and if we come to a
reasonable resolution.  If we can't then we'll revisit this.

> 2)  The example in section 1 is now broken.

D'oh.  I even complained to Nat in person about how this was broken, but
didn't actually fix it.  I'll just fix this - since the sample only has one
frame, it's not really impacted by (1).

- James

> Fixing #2 is easy.
> Fixing #1, I'm not sure.  If performance.now() doesn't change, then we
> probably need to first walk all the documents and gather up the relevant
> now() values, and only then start making the callbacks...  Or something.
>  In any casem the current setup makes no sense.
>  My understanding is that this is consistent with
>> Mozilla and Chrome's expected behavior.
> The spec as written is definitely not consistent with anything we'd ship.
>  ;)
> -Boris
Received on Monday, 14 May 2012 22:05:15 UTC

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