W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2011

Re: [Performance Timeline] Need higher resolution timers

From: James Robinson <jamesr@google.com>
Date: Wed, 24 Aug 2011 14:47:51 -0700
Message-ID: <CAD73mdLQ6_uxq_jm9xDSoTo5H2BApkiNJtLKooTZBvhiMSOHHw@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: James Simonsen <simonjam@chromium.org>, public-web-perf <public-web-perf@w3.org>, Zhiheng Wang <zhihengw@google.com>
On Wed, Aug 24, 2011 at 2:41 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Based on the thread comments, our decision to use a monotonic clock was
> partly driven by not wanting the timestamps to be compared with Date.now(),
> which is subject to system clock changes, so my originally concern here is
> not an issue. ****
>
> ** **
>
> Per the WG discussion today, we are proposing that all timing attributes
> returned from the new getEntries() methods be defined in sub-millisecond
> resolution in terms of a monotonic clock measuring time elapsed from the
> beginning of the navigation of the root document (navigationStart). In order
> to preserve compatibility of performance.timing (Navigation Timing), getting
> timing attributes directly from performance.timing will continue to return
> millisecond resolution from the Unix epoch. Does anyone see a concern with
> this approach?****
>
> ** **
>
> Likewise, would requestAnimationFrame timestamp also use this new timebase?
>

I think that we want to do this as well - I was going to send out a proposal
for exactly this once we reached consensus on this thread (which it seems
like we have).  Excellent!

- James

>  **
>
> Jatinder****
>
> ** **
>
Received on Wednesday, 24 August 2011 21:48:23 UTC

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