[webkit-dev] High Resolution Timer API proposal(s)
robburns1 at mac.com
Fri Oct 3 10:53:06 PDT 2008
On Oct 3, 2008, at 8:36 PM, 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.
I was going to raise the same issue. Again, I'm wondering how many
legitimate uses are there for short timeouts in background tabs/
windows. For example, the calendar app sets a timeout minutes, days or
hours in the future and those timers could fire in the background.
However, for timers set for under 1000 milliseconds, aren't these
simply resorting to polling. By inhibiting timers when pages are in
the background (especially with new timer APIs), we encourage web
application authors to find more appropriate events to key off of.
Polling may be a popular design pattern, but we should be thinking of
ways to painlessly break that approach, not facilitate it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev