[webkit-dev] setTimeout as browser speed throttle
pkasting at chromium.org
Tue Sep 30 10:29:47 PDT 2008
Sigh... re-sending since I used the wrong email address the first time.
On Tue, Sep 30, 2008 at 10:25 AM, Peter Kasting <pkasting at google.com> wrote:
> On Mon, Sep 29, 2008 at 8:06 PM, Maciej Stachowiak <mjs at apple.com> 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev