On Oct 3, 2008, at 10:36 AM, Peter Kasting wrote:
On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood
<[EMAIL PROTECTED]> 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
problems.
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.
- Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
