[webkit-dev] setTimeout as browser speed throttle

[David Hyatt]

Note that these problems in Safari came from having no clamp at all.   
Even Chrome has a 1ms clamp.

I think a lowered clamp is a good idea though.  I originally wanted to  
change the clamp to 5ms back when I implemented the code to keep one  
shots unclamped, but got talked out of it by people worried about  
animation speed being too fast.  I really don't think that should be  
much of a concern, and so the idea of a lowered clamp continues to be  
attractive to me.

Even better would be to tweak the clamp as needed if you could detect  
that you are idling (and maybe lower the clamp dynamically).  That  
might be too much rocket science though. :)

dave

On Sep 30, 2008, at 3:58 PM, Darin Adler wrote:

> This debate is not new. We tried this in WebKit, when we first
> released Safari.
>
> We repeatedly encountered pages that behaved well in other browsers
> and did not behave well in Safari, and the root problem was that they
> had an effective minimum timer value.
>
> It's arrogant to say that it's a website problem. Until the browser
> has a large market share, almost all misbehaving sites are browser
> problems, not website problems.
>
> We saw similar issues with GIF frame timing before we got the minimums
> right there too.
>
>> 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").
>
>
> This is an incorrect straw man argument that you're putting forward
> repeatedly and forcefully.
>
> We started the Safari project with the naive view that there was no
> need for a minimum timer value. Then we changed this in WebKit because
> of sites that were misbehaving and real bug reports. The new value is
> clearly close enough to the value in the top market share browsers
> that these incompatibilities are effectively a thing of the past.
> Unless we bring them back by removing that minimum again!
>
> You keep stating that CPU usage isn't "a compatibility problem" and
> that these concerns were not real. But that seems to be an unimportant
> semantic distinction. We had to do this to get Safari to behave
> properly with many real websites. I'm sorry that it's difficult to
> quickly find examples now, but I trust there are still many sites out
> there with this issue.
>
> After the many years of the challenging task of fixing incompatible
> websites one at a time, I'm loathe to undo a change that was made to
> fix specific websites. Some of the value in the WebKit project is the
> accumulated knowledge about what matters in practice for
> compatibility. This is definitely one of those things.
>
>     -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev