On Sep 30, 2008, at 10:42 AM, Peter Kasting wrote:
2008/9/30 Mike Belshe <[EMAIL PROTECTED]>
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.
That seems like incorrect reasoning to me. unclamped setTimeout(0)
does not break processing of user events in a single-process browser
(I tested). But it will equally drain your laptop battery and produce
a great deal of heat and noise with single-process and multiprocess
architectures.
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.
At the extreme, performance issues can be 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.
I think if we agree that there should be some lower bound on the
normal timer API, to protect against sites only tested in normal
browsers, then we would want to also introduce a high resolution timer
API with no limit for aware apps to use. In which case it seems
prudent not to change the timeout from the range of what other
browsers do. That way there is no risk to legacy content, but new
content can get the full benefit (rather than being throttled to 3ms
or 1ms).
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
