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. 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. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev