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

RE: [Performance Timeline] Need higher resolution timers

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 24 Aug 2011 21:41:43 +0000
To: James Robinson <jamesr@google.com>, James Simonsen <simonjam@chromium.org>, public-web-perf <public-web-perf@w3.org>, "Zhiheng Wang" <zhihengw@google.com>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B0406911B56@TK5EX14MBXC252.redmond.corp.microsoft.com>
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?

Received on Wednesday, 24 August 2011 21:42:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:09 UTC