[ck2]

Again, you are only testing the accuracy (and impossibility) of a 1ms setInterval in javascript which cannot happen.

Here is your previous canvas test I modified to a real "zero" timeout

http://jsbin.com/owino3

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.

[ck2]

Just adding some documentation about the limits of setTimeout and setInterval - Chrome has now settled on 4ms minimum (HTML5 standard) and Firefox 3 throttles lower values back up to 10ms minimum:

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.

[hertog]

I understand what you are saying, but I thought that it wouldn't matter for browsers on mobile devices. I thought that the performance on a mobile device was slow enough to ignore the setInterval limit. Apparently not, since your test gives me a 200fps on my iPhone 3Gs.

However, although the fps is higher, the animation looks worse. Is that because the 'render cycle' is not completed using this technique?

[ck2]

It's because browsers render in memory and then periodically update the video display with a "snapshot" copy. Typically this method is fine for the regular content of an average webpage.

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.

[ck2]

Just for "fun" I tried (abusing) the blaze.io screencapture service but it's snapshots unfortunately are way too slow

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)