[webkit-dev] setTimeout as browser speed throttle

Peter Kasting pkasting at chromium.org
Tue Sep 30 10:42:57 PDT 2008

2008/9/30 Mike Belshe <mike at belshe.com>

> As for keeping the fan off - if we could keep the CPU idle a 3ms minimum
> timeout loop does that resolve your concern?

Followup to my earlier post, based on this.

I realize that one reason why we (Chromium folks) have not been as concerned
about CPU usage is that in a multi-process world, excessive CPU is an
annoyance, but doesn't completely break the app.  This wouldn't necessarily
be the case in a single-process consumer of WebKit, e.g. Safari, where a
page in a tight JS loop could make the whole browser less responsive.  This
seems like a legitimate reason to be concerned about excessive CPU usage.
 Mike's suggestion that we can find a minimum timeout value (e.g. 3 ms)
where the CPU doesn't get pegged seems reasonable if this is the main issue.

And a few more thoughts on app compat.  Using more CPU is not an app compat
concern.  The CG GIF decoder that Safari uses burns 10x the CPU that Gecko's
does, such that on various animated GIFs I can hit 60% of one of my (very
fast!) cores just animating a single image in Safari.  But no one has ever
presented this as a "web app compat" issue, even though tons of web pages
use animated GIFs; it's just a bug/optimization opportunity.  Chromium uses
extra CPU due to having plugins out of process.  Gecko uses more CPU to
relayout than WebKit.  None of these are compatibility issues.  The comments
on bug 6998 imply to me that the 10ms cap was put in because Safari was
eating more CPU than other browsers, not because there were animations
running at the wrong speed or stylesheet loads not being sensed soon enough.

I think if we can agree that not pegging the CPU, rather than precisely
matching other browsers (which is impossible due to their 60% variance from
each other), is the chief objection to uncapped timers, it will be easier to
move forward.

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

More information about the webkit-dev mailing list