[webkit-dev] setTimeout as browser speed throttle

[David Hyatt]

On Sep 30, 2008, at 9:37 AM, Mike Belshe wrote:

> Thanks for the concrete examples, Dave!  I tested all 3 of these,  
> and haven't yet found any problems.  But I don't have specific  
> URLs.  I also looked through the webkit bugs database as much as I  
> could, and could not locate them.
>

When these problems occur they are usually bugs in the Web site that  
do (eventually) get discovered and fixed.  In the past our evangelism  
people have had to contact sites to fix these kinds of issues.  This  
is why simply surfing to sites doesn't really give an accurate picture  
of how this works.  In our experience, sites redesign or add new  
features (this was the case with Amazon), and the new feature will  
have a setTimeout use that wasn't tested in Safari.  With no clamp,  
we'd end up eating 100% CPU until the site fixed the problem (which  
could take months sometimes).

> BTW - if the primary concern is not spinning the CPU, we could just  
> drop the throttle down to 2 or 3ms, and the CPU will be largely idle  
> on most machines.  In a few years, with faster processors, we'll be  
> able to drop to 1ms and still have largely idle CPU.
>
> Would 3ms be viable in your eyes?
>

Yes, I was considering this also.  To me the primary issue with  
removing the setTimeout clamp is CPU hogging and not animation speed.   
I do think lowering the clamp is reasonable.  I still think we should  
have an unclamped high res timer API though, regardless of what we  
decide with setTimeout.

dave