A Survey of JavaScript Timers on Mobile

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

Figure 1: Chrome 20 and Firefox 12 have high resolution, scalable and consistent timer implementations

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.

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.

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.