Sigh... re-sending since I used the wrong email address the first time. PK On Tue, Sep 30, 2008 at 10:25 AM, Peter Kasting <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 8:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > >> 1) Animations that run faster than intended by the author (it's true that >> 10ms vs 16ms floors will give slight differences in speed, but not nearly as >> much so as 10ms vs no delay). >> > > I disagree that 10 vs. 16 ms is a slight difference. I don't think there's > sufficient compatibility in the current landscape for authors to rely on > this. Furthermore, most/all animation I've seen is done as either animated > GIFs or Flash, because of the comparative reliability of the timings and > ease of preparing the animation. (Even here, browsers don't all agree: GIF > throttling varies across browsers, WebKit's GIF timings can be off by 50% or > more without a patch I've recently posted for review, etc.) > > >> 2) Burning CPU and battery on pages where the author did not expect this >> to happen, and had not seen it on the browsers he or she has tested with. >> > > I don't view extra CPU as a web compat issue. It's an issue, but not a > compatibility issue, and therefore not one that has to be the same across > browsers. > > Besides which, as Mike mentions, we've retested the "in the wild" pages > where this supposedly occurred and haven't seen it reproduce. I don't > believe the massive headache Hyatt predicts is going to be massive, even if > no one else adopts Chromium's behavior. > > Darin Adler's comment on bug 6998 was "it's really a mistake to ask for > timeout 0 if you don't want to be called > as fast as you can" and I agree. This is another case where people have > IMO mistakenly "standardized" a behavior that does not require consistency, > based on a Windows limitation from long ago. A better course here is to > unclamp timers and file bugs against other browsers requesting that they > unclamp too. (Once again, see the very similar situation with GIF > throttling, where Firefox differs from other browsers and is IMO much more > correct.) > > I don't think we should propose a new API here. This is not a question of > risking breaking the web. This is a question of noticeably better > performance on a large number of web pages, and an API that does what > authors expect (and many authors already think it does), versus the > _possibility_ of extra CPU usage on some sites (which we haven't seen > widely, we're just speculating about) until they make a one-character fix to > their JS. In a world where Gecko is willing to change layout behavior in > ways that visibly break sites in order to fix bugs, and IE 8 will do > similarly for internet pages unless authors switch it to compat mode, I > think the worst-case harm of this change is still insignificant. And I > think if we can get Mozilla to switch their behavior as well it will be even > less significant. > > PK >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
