[webkit-dev] setTimeout as browser speed throttle
oliver at apple.com
Tue Sep 30 14:47:47 PDT 2008
On Sep 30, 2008, at 1:41 PM, Peter Kasting wrote:
> On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson <beidson at apple.com>
> If we add a new well specified API that all browser vendors agree
> on, everybody wins.
> No; everybody who's willing and able to change wins.
> Everyone else wins or loses depending on whether the new behavior is
> better or worse for them. My argument is that this makes life
> better for nearly all pages affected. The entire reason to change
> setTimeout() is precisely _because_ not everyone will change their
> web pages.
Okay, lets try this, there a 3 possibilities win, no change, and lose,
here are the groups:
New API No timer clamp
Benefits from higher precision timer No change Win
Hurt by high precision timer No change lose
Hurt by timer and willing to update No change lose (extra work)
Benefits from timer and willing to update Win Win
So while two groups "win" with the chrome model, two groups actually
lose either due to site breakage, or having to do extra work to avoid
breakage. Whereas with a new API while only one group actually "wins"
no others are effected.
> (Furthermore, I claim the number of people who will realize they
> could get something better, and change their code to get it, is
> lower than the number of people who will see that something is wrong
> and fix it.)
I would disagree -- people who need high precision timers, and realise
that they're there *will* use them. Sites that are broken by a buggy
setTimeout implementation won't. Hell I have seen sites with actual
bugs (eg. bugs in the site, not in the browser) where i have provided
an actual patch to correct the bug and they still don't fix it. All a
broken setTimeout implementation will do is result a site making the
"easy" change of saying "don't use this browser because it's broken".
They do that even when the bug is in their site, so an actual browser
bug is even easier to ignore.
> negates the need to introduce new incompatibilities into the already
> published web by changing setTimeout().
> This still implies there is a meaningful compatibility hit to making
> this change. I have not yet seen any reason to agree that is the
> case (in the sense of "CPU usage is not a web compatibility
> issue"). There is _already_ no compatibility here. Browsers do
> completely different things, of an equivalent magnitude (6 ms) to
> the suggested change of 10 ms -> 3 or 4 ms. Firefox is even
> different based on whether Flash happens to be running! How can
> there be compatibility problems introduced by this proposal that
> don't already exist?
Um, i would guess on Vista all browsers have a 10ms timeout, on XP the
only reason the 15ms timeout clamp exists is because of XP's low
default timer resolution. On Mac and (I assume all unixes/bsds/linux)
the timeout clamp is likely to be 10ms. But even the 15ms timeout is
only 1.5x longer that 10ms, where as 1ms represents an order of
If we were to look at a game that for instance assumed a 15ms clamp on
setTimeout, and used that as the game clock tick (which happens) then
a game that used to get maybe 50 updates a second will get 66 updates
if you have 10ms timer. With a 1ms resolution timer though the game
will get *160fps*, eg. 3 times faster than was intended.
which uses a 0ms timeout to trigger torpedo motion
yesterday that had to LIMIT the framerate because google chrome made
it unplayable." -- so there are sites that have already had to do work
to not break with this model -- how many else are out there?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev