[webkit-dev] High Resolution Timer API proposal(s)

[Maciej Stachowiak]

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  
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/11746ab3/attachment.html