[webkit-dev] setTimeout as browser speed throttle

Brady Eidson beidson at apple.com
Tue Sep 30 10:21:01 PDT 2008


Agreeing with Alexey's points here and adding one more...

On Sep 30, 2008, at 9:32 AM, Alexey Proskuryakov wrote:

> Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
>
>> Thanks - I did see that bug.  Intentionally spinning the CPU vis
>> setTimeout(,0) is not a problem if it is what the application
>> intended.
>
> I don't quite agree - even though this may have been the intention,
> the application developer will not be aware of all the consequences
> without testing in Safari/Chrome. The site will work perfectly in IE
> and Firefox, but in WebKit-based browsers, it will eat battery, make
> the computer too hot to hold on one's knees, and change the pitch of
> noise coming from it. These are quite practical issues.
>
> It may also work "faster" - but chances are that this delay is not
> important for user experience, given that the code was deployed and
> works adequately in other browsers.

And, as Maciej pointed out with the JQuery case, it may also cause the  
application to work SLOWER.  It seems likely that JQuery uses  
"setTimeout(0)" not because they expect their code to actually run  
cyclically with zero delay, but because they are aware that "0" in  
this context means "minimum," well aware that this means 10ms or  
15.6ms for a vast majority of users.

Introducing this incompatibility would make WebKit-based browsers  
broken compared to all other major browsers.  And it would not be a  
simple 1 character fix as you suggest, as thousands of websites have  
thousands of copies of dozens of versions of JQuery and there is no  
master rollout that could fix them all at once.

And pretend you do fix them after a lengthy battle - what happens when  
you identify the next ill-behaving component?

I think that dancing around "setTimeout() has no specified minimum  
timeout" as an argument for adding this incompatibility is kind of  
crazy.  True, there's no spec or standard that decides between 10ms,  
15.6ms, or some other value.  But the web has already decided a de- 
facto standard which seems to be more important than a spec in this  
case.

I, too, fully support a high res timer API as a separate, cross- 
platform addition.

~Brady

>
>
> Otherwise, I certainly agree that having a high resolution timer
> support is a good idea.
>
> - WBR, Alexey Proskuryakov
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



More information about the webkit-dev mailing list