- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 12 Apr 2011 13:47:36 -0700
- To: James Simonsen <simonjam@chromium.org>
- CC: public-web-perf@w3.org
On 4/12/11 12:57 PM, James Simonsen wrote: > One of the original goals was to be able to compare easily with Date > objects. Instead of that, perhaps we should expose a monotonic clock to > the page? Longer-term, I think that this is the right direction to go. Gecko already uses a monotonic clock internally for its animations and then has to do some hackery to report "corresponding" times to the web page that are compatible with JS Date... Exposing a monotonic clock to pages would solve that problem. On the other hand, an issue with monotonic clocks is that you can't really use them to record "the time right now" except in some sort of opaque timestamp format. They're very good for measuring time intervals, of course. Are people ok with exposing opaque timestamps (that can't necessarily be converted to wall-clock time, etc) to JS? For the particular case of navigation timing one possibility is that the page load start is recorded as wall-clock epoch time and the other times reported by the interface are defined in terms of a monotonic clock measuring time elapsed from the page load start. That would be API-compatible with the existing spec, I think, but ensure that the differences between the reported numbers actually correspond to elapsed durations. -Boris
Received on Tuesday, 12 April 2011 20:48:09 UTC