- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Tue, 12 Apr 2011 14:37:58 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: James Simonsen <simonjam@chromium.org>, public-web-perf@w3.org
On 04/12/2011 01:47 PM, Boris Zbarsky wrote: > 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 > If web developers are already complaining about this bug in the spec, it is better to fix it now. I support what Boris suggested above. -Olli
Received on Tuesday, 12 April 2011 21:39:22 UTC