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

Re: [HighResolutionTime] performance.now() value depends on the document, which can cause problems

From: Tony Gentilcore <tonyg@google.com>
Date: Wed, 30 May 2012 10:19:08 -0700
Message-ID: <CANvLf_FsSV8cgW8-fY1hHYaXaPw-uWT9iNvr-raQxp9XafUK3w@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: James Robinson <jamesr@google.com>, public-web-perf@w3.org
There's another tradeoff: it's desirable for now() to be comparable to
the values returned by performance.timing. For instance, a child frame
calling now() in the load event should get a value similar to
"performance.timing.loadEventStart -
performance.timing.navigationStart".

The last two expectations in this test demonstrate:
http://w3c-test.org/webperf/tests/submission/Google/HighResolutionTime/test_cross_frame_start.html

(A) requires now() to be comparable across frames and (B) requires
now() to be comparable to the frame's timeline.

The implementation on Chrome's dev channel passes (A), but still has
the bug that it does this regardless across origins. We totally break
the use-case in (B). Jatinder, what does IE do here?

A shared timebase per origin and a non-zero navigationStart on
subframes might just be the best solution.

-Tony

On Mon, May 14, 2012 at 6:16 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/14/12 5:58 PM, James Robinson wrote:
>>
>> I like the idea that same-origin frames share a timebase, but I don't
>> think walking window.parent is sufficient.  You could have sibling
>> iframes that are the same origin as each other and are scripting each
>> other but different origin from their parent.  I think this proposal
>> really boils down to keeping a timebase for each unique origin within a
>> top-level browsing context.
>
>
> Why limited to a top-level browsing context?
>
>
>> and getting the origin has to be fast to make other JS
>> accessors fast.
>
>
> Unclear.  This is not the case in Gecko, say....  Or more precisely, getting
> a _string_ origin is fast in Gecko, but there is no object that represents
> an origin, so the cost would basically be equivalent to a hashtable lookup
> unless more code restructuring happens.  Which might need to happen, of
> course.
>
>
>> If authors are doing this in JS
>
>
> Then we lose.  Let's avoid that.  ;)
>
> -Boris
>
Received on Wednesday, 30 May 2012 17:20:13 UTC

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