[webkit-dev] setTimeout as browser speed throttle

[Peter Kasting]

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 <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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/3cc958bd/attachment.html