[webkit-dev] setTimeout as browser speed throttle

Maciej Stachowiak mjs at apple.com
Tue Sep 30 17:35:28 PDT 2008

On Sep 30, 2008, at 5:15 PM, Mike Belshe wrote:

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

Degree of difference matters too, not just whether there is one. For  
example, a browser using a different antialiasing algorithm for text  
would be much more acceptable than a browser that renders black text  
as bright yellow, event though both in theory could make a page look  
different than intended.

In practice, a timer value of 10ms instead of 15.6ms does not appear  
to be a problem, we have historic evidence that 0ms minimum is a  
problem, scattered evidence that 1ms may be a problem, and no clear  
information on values in between such as 3ms, 5ms or 7ms.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/60b13808/attachment.html 

More information about the webkit-dev mailing list