[webkit-dev] High Resolution Timer API proposal(s)
mjs at apple.com
Fri Oct 3 13:42:23 PDT 2008
On Oct 3, 2008, at 10:36 AM, Peter Kasting wrote:
> On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood
> <jhaygood at reaktix.com> wrote:
> I'd say define it as a minimum precision of 1ms, but browser
> manufacturers can define any precision they wish.
> OK, but that only pushes the problem space outward rather than
> solving it. Make CPUs 10x faster and then have one browser with a
> floor of 1 ms and one with 0.1 ms and you have the exact scenario
> we're in today. Someone writes a tight loop in the 1 ms browser,
> checks that it doesn't use too much CPU, and pushes the build, and
> the 0.1 ms browser gets hosed.
> I admit that this one worries me a bit.
My proposed requirement was that 0 timers must be processed as soon as
possible (on the next return to the event loop) and that besides that
accuracy to at least 1ms should be provided, but more if possible.
I think 0-delay timers are the most interesting use case and the most
likely to be set to repeat as an author mistake. A repeating
indefinite 0-delay timer will quite likely hose any browser supporting
this API per spec, so it shouldn't be a source of future variance
I think the use cases for repeating timers with very small but nonzero
delays will be pretty rare; I doubt many authors specifically want a
1ms indefinite repeat for instance. So I think the difference between
1ms and .1ms will be less likely to be a future issue. If we are
worried, though, we could require a 1ms floor for repeating or nested
timers after some number of repeats (some largeish number, like 100)
if we judge that having a crazy-fast repeating timer indefinitely is
unlikely to be a valid use.
I recommend sending further feedback to public-webapps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev