[webkit-dev] setTimeout as browser speed throttle
mike at belshe.com
Tue Sep 30 17:15:31 PDT 2008
On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:
> Subjective note:
>> I'm much more worried about sites spinning the CPU accidentally (e.g. they
>> used setTimeout(0) somewhere by accident) than I am about frame rates on
>> games. Using the clock as your frame rate is super buggy, and sites need to
>> know better. It won't work now and it won't work going forward.
>> If you recall - there used to be a "TURBO" button on PCs as they made the
>> switch from 8MHz to 12MHz to address this issue. Turbo buttons don't exist
>> Anyway, this is a personal preference; I have little sympathy on the game
>> front - but more sympathy on the accidental CPU front.
> Our attitude towards Web compatibility generally is that if a Web site
> works reasonably in other browsers but does not work in Safari, then it is
> presumptively our bug. That is what users will assume, and lectures about
> how foolish the site developer was tend to have little effect. Thus,
> sympathy or lack thereof for particular use cases does not enter into the
> picture. We should not be making these kinds of decisions based on our own
> personal opinions of the coding quality of the site.
If you follow this to the logical conclusion, then WebKit should use a
15.6ms timer. :-)
My point is that applications which are hard coded to work with a particular
minimum timer value are broken already today across browsers (some are 10,
some are 15, and these are significantly different). Such applications were
probably built and tested on a limited set of browsers, but it does not
matter why they are this way. Given that these apps already behave
differently in existing browsers, I'm much less concerned about this issue
than the CPU issue.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev