[webkit-dev] setTimeout as browser speed throttle

Mike Belshe mike at belshe.com
Tue Sep 30 11:23:51 PDT 2008

>  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.

OK - I created a second version of my timer test to help with testing of
this.  (these are only interesting tests to run on browsers which unclamp
the timers)

Here is the test I created before:  http://www.belshe.com/test/timers.html
The problem is that this will use lots of CPU just doing paints (it paints
with every iteration).  Most background spinners don't have this property.

This case only updates the UI every 1000 iterations.  With this test, the
CPU load is almost zero even with a 2ms timer.

Using a slightly more conservative minimum should account for slower
processors and also allow for a little more work to be done in the
setInterval loop.

Regarding the API - yes.  I'd like the units of time for the new API to be
at most measured in microseconds; 100-nanos might be more forward-thinking.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/2eea1efe/attachment.html 

More information about the webkit-dev mailing list