RE: DOMHighResTimeStamp property giving platform time for DOM events

Hi Rob,

I've looked at the use cases presented by Pablo, http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html, and a high resolution analogous of Event.timeStamp seems very interesting. Considering the Web Perf working group is currently in the process of re-chartering and we have additional ideas that we want to consider for High Resolution Time, I think this is something we will consider in V2 of the High Resolution Time spec. We should start making progress on that soon.

Thanks,
Jatinder


From: flackr@google.com [mailto:flackr@google.com] On Behalf Of Robert Flack
Sent: Friday, October 12, 2012 7:22 AM
To: public-web-perf@w3.org
Cc: Anne van Kesteren
Subject: DOMHighResTimeStamp property giving platform time for DOM events

Hello,

This discussion originally started back in March (http://lists.w3.org/Archives/Public/public-web-perf/2012Mar/0034.html) and as suggested was moved to the www-dom mailing list where after some discussion and cases where the timestamp would be useful (http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0092.html) it was suggested that we move it back to the web performance spec (http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html) since we use this spec as a baseline to be able to compare these monotonic timestamps.

I've put a patch up for review with a proposal implementation of this feature (https://bugs.webkit.org/show_bug.cgi?id=94987) in WebKit which uses the PlatformEvent timestamp to accurately provide the monotonic system time responsible for the creation of the DOM event as a time since document load consistent with Performance.now(). I'd love to see this added to the spec so that we can track the latency of events in ECMAScript since arrival to the system kernel.

Since the spec for Event.timeStamp requires a 1970 epoch based time it is unsuitable for measuring the latency of events at a high level for the same reasons Performance.now() exists.

Thanks for the help in moving this discussion forward,
Rob