[webkit-dev] setTimeout as browser speed throttle

[Mike Belshe]

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

http://www.belshe.com/test/timers2.html<http://www.belshe.com/test/timers.html>
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.

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