- From: James Simonsen <simonjam@chromium.org>
- Date: Mon, 22 Aug 2011 15:31:07 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAPVJQi=A5ru9H40KZTnh_=6EYv5eRaEAPgmu5Q5oJBGuN-DmZg@mail.gmail.com>
Hi web-perf, So far, we've spec'd the Performance Timeline to use 64-bit ints of milliseconds. This has mostly been so that the times look like Date.now(). It's also sufficient for network timing. However, looking longer term, there's a need for more precision. One example is graphics, where milliseconds are already insufficient for measuring frame rate. Down the road, as games and apps get more sophisticated, we can expect people to want to time things within a frame. Switching to a double seems like the easiest solution to adding more resolution. However, I'm a bit worried we're running out of bits. Date.now() returns milliseconds since 1970 and we're currently spec'd to use the same offset. If we switch to double, we've already consumed 40 of the 52 bits available just measuring milliseconds since 1970. Getting to microsecond resolution leaves us with only 2 spare bits. That seems a bit tight. If we throw out that 1970 offset, we can get much higher resolution times. I propose we just measure time since initial root document navigation (and hope nobody leaves the same page open for 40 years). It could be stored as a double of milliseconds. James
Received on Monday, 22 August 2011 22:31:40 UTC