[webkit-dev] setTimeout as browser speed throttle
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
> 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
I, too, fully support a high res timer API as a separate, cross-
> 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
More information about the webkit-dev