It wasn’t too long ago that web developers were struggling with poor implementations of JavaScript timers in desktop browsers. John Resig’s survey of desktop browser timers at the end of 2007 showed serious problems with timer resolution and/or timer consistency on all tested browsers. The practical effect of this was that JavaScript animations could run at different rates in each browser, choke up when too many concurrent timers were active, and often display stutter and jerkiness. (For more background on how timer resolution affects the user experience (and why we need a special Animation timer), Nicholas Zakas blog post on JavaScript animation is quite helpful.)

“Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer platform.”

Since then, JavaScript timers on desktop browsers have improved vastly. Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer. This was soon matched by other browsers, and as a result, web developers have become used to respectable performance from JavaScript animations in desktop browsers. The most recent version of every major browser except IE has a 4ms timer with very good consistency even as the number of concurrent timers gets larger than 100. Internet Explorer before Windows 7/IE9 used the low resolution system timer as its JavaScript timer – which gave a 15.6ms timer resolution. This changed in Windows 7, which now offers two different resolutions, the old 16ms timer when your device is in power-saving mode and a new 4/5ms timer when in normal mode. (This configuration can be changed in advanced power options.)

JavaScript Animation on Mobile

However, mobile browsers have been a different story. The conventional wisdom has been that JavaScript animations on mobile can suffer from stutter and synchronization problems. This is one of the reasons that CSS Transforms and Animations have become a popular way to perform mobile animations since content movement is performed in hardware by the GPU and gets the benefit of sub-pixel tweening. However, there hasn’t been much written about mobile timers, so we decided to do a semi-scientific study of timer performance by running John Resig’s timer test on 20 or so of our mobile test lab devices. The test animates a pixel using setInterval() at 0ms timeout at various levels of concurrency and call stack depth. We tested devices running iOS3 through iOS5 on iPhones, iPads and iPods, Android 2.2 through 4.1 on Samsung, LG, HTC, Huawei and Motorola devices, as well as the RIM Playbook 1 and 2. Here’s what we found:

Timer Resolutions

Most mobile devices we tested had timers set at 10ms resolution. This was the case for the vast majority of Android devices, as well as devices running iOS3 and iOS4. Chrome for Android and iOS5 had faster timers: their timer resolution was 4ms. And the Blackberry Playbook 2 had the slowest timer: approximately 17ms. One outlier for the Android browser was the Motorola Droid 2 Global which had a timer resolution of 16ms. Finally, when we ran the timer test on our “straight-from-Google-IO” Nexus 7 tablet running Android 4.1 and Chrome for Android, we got an odd result which showed the timer whipsawing from 4ms to 10ms. (This may due to some webkit behavior that backs the timer off to 10ms, if it’s already processing a timer callback, but would love to see if anyone from the Chrome team has insight on this.)

In other words, the most recent devices running Android 4, Chrome for Android and iOS5 have desktop-class timer resolutions, while older Androids and RIM devices have timers that are 2x to 4x coarser grained.

Timer Consistency and Scalability

Next we looked at the variability of the timer measurements at various levels of timer concurrency and stack depth. The ideal performance result is a horizontal line at the y coordinate of the timer resolution—whatever that is. Here the results were a little varied.

Our star performers were the iPhone and iPad2 (below left), as well as the Motorola Xoom running the stock Android ICS browser (below right). Each were highly consistent at their respective timer resolutions of 4ms and 10ms, with no deterioration as the number of timers increased, and just one or two spikes. Other notable performers were Chrome for Android on the Motorola Xoom and one of our Samsung Android 2.3 devices.

iPad2 running iOS5

Motorola Xoom running Android ICS

More typical, however was a drift of anywhere from -5ms to +10ms around the expected timer resolution, particularly when the number of concurrent timers exceeded 8. This was true across all Android handset makers and all versions of Android 2. The typical result from an Android 2.x device looked something the example below—in this case, a Samsung phone running Android 2.3.5.

A Samsung phone running Android Gingerbread

Finally our worst performing devices. Surprisingly, one of these was from Apple. While all our iPods had noisy performance graphs, our iPod/iOS5 was particularly poor—with a few spikes that were literally off the chart. We also found the Playbook 2 timer to be extremely noisy, regularly spiking to 2x the 18ms timer resolution.

iPod running iOS5

Blackberry Playbook running Blackberry OS

Lessons learned and conclusions drawn

Our survey of mobile timers shows mostly good news. The most recent mobile browsers on Android—both stock Android and Chrome for Android now have desktop quality timers. Surprisingly, it doesn’t look like Apple is taking particular care to achieve good performance on the iPod browser. For highest performance on iOS, this probably means it’s best to stick with GPU-accelerated 3D transforms for the moment. It also reiterates the need for wide adoption of the work-in-progress animation timing spec.

Written by Michael Mullany

Michael Mullany is the CEO at Sencha. He has held various product and executive marketing roles at influential Silicon Valley startups -- Netscape, Loudcloud, and VMware. He holds an MBA from Stanford University and a BA in economics from Harvard College.

Comments

This sounds all so familiar, I’ve been using the mobile web as a platform for over a year now. And within that year I’ve seen many performance gains, especially in animation. But there is definitely still work to be done on that side.

Luckily Google finally did the right thing and released Chrome for Android. Apple could also push things ahead a lot further, I wonder why they’re holding back. The worst part on the Android side is the (feature) phones which are not able to upgrade, even device manufacturers like Samsung and HTC don’t put enough effort in keeping their devices up to date in my opinion.