|Summary:||Add currentTickCount() to get monotonically increasing time|
|Product:||WebKit||Reporter:||James Simonsen <simonjam>|
|Component:||WebCore Misc.||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, darin, dino, fishd, igor.oliveira, jamesr, mjs, simon.fraser, tonikitoo, tonyg, yong.li.webkit|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
Description James Simonsen 2011-05-16 17:36:17 PDT
We need a way to measure time without being affected by changes to the user's clock. Tick count should provide a monotonically increasing time that can be used to measure duration. We'll use this for Navigation Timing and it will also be useful for timing animations.
Comment 2 James Simonsen 2011-05-16 17:39:32 PDT
This is just a primitive initial implementation. Each platform will need to implement this currentTickCount() correctly.
Comment 3 James Robinson 2011-05-16 17:42:31 PDT
Comment on attachment 93719 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=93719&action=review > Source/WebCore/platform/chromium/SystemTimeChromium.cpp:48 > + uint64_t tickCount = static_cast<uint64_t>(currentTime() * 1000000.0); why is this currentTime() * 1000000.0 when the wtf/ version is currentTimeMS() * 1000.0? nit: i'm bad at counting zeros so I like to write this sort of expression as 1000 * 1000
Comment 5 James Simonsen 2011-05-16 17:49:40 PDT
(In reply to comment #3) > (From update of attachment 93719 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=93719&action=review > > > Source/WebCore/platform/chromium/SystemTimeChromium.cpp:48 > > + uint64_t tickCount = static_cast<uint64_t>(currentTime() * 1000000.0); > > why is this currentTime() * 1000000.0 when the wtf/ version is currentTimeMS() * 1000.0? It means an extra #include. I changed it so they match. (Note that the Chromium version will be replaced shortly anyway.)
Comment 6 James Robinson 2011-05-16 17:56:00 PDT
+cc some folks for comment on the API Monotonically non-decreasing isn't the most interesting property - uniformly increasing is. I think this is a step in the right direction and assume that we'll want to implement this with the appropriate system APIs (mach_absolute_time(), QueryPerformanceCounter(), etc). I'm not sure "tick count" is the correct thing to call this - in chromium we call this TimeTicks, although in practice I always want to use this sort of API to measure intervals or durations.
Comment 7 David Levin 2011-05-16 19:49:31 PDT
Comment 8 Alexey Proskuryakov 2011-05-16 23:14:28 PDT
The name "tick count" is quite opaque. Are you intentionally abstracting away how long a tick takes? Why is it not 1/60th of a second? > Monotonically non-decreasing isn't the most interesting property - uniformly increasing is. I wonder if uniformly increasing time across sleeps can be implemented on a sufficiently large amount of platforms.
Comment 9 Dean Jackson 2011-05-17 05:34:04 PDT
I'm more interested in the duration of the document. I wonder why you describe the API as from an arbitrary point? Also, like JamesR, I expect this to be always increasing, not not-decreasing. It seems that in the current patch the tick would stop for an hour if the user's real clock moved backwards an hour. Also, you never assign lastTickCount = tickCount. (Maybe you meant to do that in both return cases, in which case the tick would only stop once).
Comment 10 James Simonsen 2011-05-17 10:56:07 PDT
Comment 13 James Robinson 2011-05-24 16:47:09 PDT
Comment 15 Alexey Proskuryakov 2011-05-25 23:26:30 PDT
*** Bug 61456 has been marked as a duplicate of this bug. ***
Comment 16 Yong Li 2011-05-31 07:33:31 PDT
This seems the same issue of https://bugs.webkit.org/show_bug.cgi?id=37743 Can we merge them into one?
Comment 17 Darin Adler 2011-05-31 15:04:39 PDT
*** This bug has been marked as a duplicate of bug 37743 ***
Comment 18 Eric Seidel (no email) 2011-06-02 08:28:58 PDT
Comment on attachment 94735 [details] Patch Cleared review? from attachment 94735 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).