[webkit-dev] setTimeout as browser speed throttle

[Mike Belshe]

Subjective note:

I'm much more worried about sites spinning the CPU accidentally (e.g. they
used setTimeout(0) somewhere by accident) than I am about frame rates on
games.  Using the clock as your frame rate is super buggy, and sites need to
know better.  It won't work now and it won't work going forward.

If you recall - there used to be a "TURBO" button on PCs as they made the
switch from 8MHz to 12MHz to address this issue.  Turbo buttons don't exist
anymore.

Anyway, this is a personal preference; I have little sympathy on the game
front - but more sympathy on the accidental CPU front.

Mike




On Tue, Sep 30, 2008 at 2:47 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> 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> wrote:
>
>> 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 magnitude difference.
>
> 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.
>
> --Oliver
>
> * A very quick google brought up:
> http://www.c-point.com/javascript_tutorial/games_tutorial/how_to_create_games_using_javascript.htmwhich uses a 0ms timeout to trigger torpedo motion
> * From a comment on john resig's blog "I saw a javascript game 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?
>
>
>
> PK
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/bc7cf074/attachment.html