Here is your previous canvas test I modified to a real "zero" timeout
With "zero" timeout I get 2000+ fps in firefox, 500+ fps in Safari 5 and 9000+ in Chrome 11.
(looks better in firefox/safari, in Chrome it goes so fast it's practically trying to rip spacetime)
In your original "1ms" test they are all under 100 fps except Chrome which can fire as fast as 4ms so it gets 200fps.
Basically all your tests across different browsers with your current code is only proving how fast or slow that browser engine deals with a "1ms" setInterval request. Most of them will not fire faster than 8ms, some slower and some like chrome will go down to 4ms. Then because you are using setInterval instead of setTimeout, you get a "backlog" because the event will fire regardless if the previous one was done or not.
setZeroTimeout removes the entire timer overhead from the benchmark, it fires as fast as physically possible in the browser used and the remainder of the time is simply what's leftover from drawing the canvas or svg object.
https://developer.mozilla.org/en/window.setTimeout#Minimum_d...
http://code.google.com/p/chromium/issues/detail?id=888#c4
We observed that current browsers already do not have a stable and consistent clock. As it turns out, even FF3 uses varying timer speeds of either 15.6ms or 10ms. The reason for this variance is because FF3 uses the default windows timer mechanisms by default; which have a 15.6ms clock granularity. However, these timers are influenced by the system-wide timeGetTime() API. Flash, Quicktime, and Windows Media all set timeBeginPeriod(1), which changes the clock resolution to 1ms. In this case, FF then applies a clamp to avoid sub-10ms timers. This can be tested by starting with a blank system w/ only FF running, and using this tool: http://ejohn.org/apps/timers/ Then load youtube (flash causes the beginTimePeriod to be called) in a background tab and run your test again. You'll see the clock speed drop from 15ms to 10ms. So, as you can see, a web developer today could be running IE w/ a 15ms minimum, FF, with a varying 10/15ms minimum, or another browser with who-knows-what for a minimum timeout.
However, although the fps is higher, the animation looks worse. Is that because the 'render cycle' is not completed using this technique?
But with zeroTimeout, the movement is happening so fast that the snapshot copy is behind. The browser might be only updating the video every 20ms at the fastest, while the block is moving several pixels every few ms.
But be assured the render of the block is completely happening and then being erased. It's a proper render. If it wasn't, you'd get a permanent "smear" of the results in the browser.
iphone 4.3 http://www.blaze.io/mobile-report/video/110315_1413/110315_1... (mp4)
android 2.3 http://www.blaze.io/mobile-report/video/110315_1414/110315_1... (mp4)
