> > > 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev