RE: [Performance Timeline] Need higher resolution timers

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?



Jatinder