High CPU usage compared to animated gif (tested in Chrome)

[dorianj]

High CPU usage compared to animated gif (tested in Chrome)

[fgnass]

With only one throbber and shadows turned off things already look much better.

It would probably make sense to reduce the number of animations. One approach would be to use a rotation instead of opacity animations. I did this in a jQuery plugin I wrote about a year ago: http://neteye.github.com/activity-indicator.html
The page contains 5 throbbers and uses much less CPU.

The problem is that the rotation sometimes becomes eccentric when you zoom in on iOS. Also it doesn't look that smooth with a small number of lines.

Another alternative could be using canvas, like Thijs van der Vossen did here:
http://stuff.vandervossen.net/temporary/spinner.html

[stephanerangaya]

FYI The animation works fine in every browsers but it's very slow on IE 7 to 9.

[SeanJA]

@stephanerangaya This is probably not the place for this discussion, but perhaps it is your computer? It works fine on IE9 here, I am not about to go and install a bunch of other versions of it to test though.

[fgnass]

On my machine (a MacBook Pro) all tested IE versions perform unexpectedly well, indeed they even outperform Chrome.

IE6, IE8, IE9 (running inside VirtualBox): Very smooth animation, 0-2% CPU

Among the WebKit browsers, Safari currently wins:

• Chrome 14: 8-10% (Google Chrome Renderer)
• Safari 5.1: 4-5%

The only two browsers that currently suck (CPU-wise) are Firefox and Opera:

• Opera 11: ~20%
• Firefox 6: ~41%, even up to 77% with shadows turned on (!)

The animation runs smoothly on an iPad 1, but I have no idea how to measure the CPU impact there.

I'll leave this issue open so that others can post their performance stats here, too.

[dlikhten]

Hmm, perhaps disable some options like shadow on firefox/opera until a fix is available?

[fgnass]

When forced into using a setTimeout()-based animation with 16fps, the CPU usage drops to ~20% in both Opera and Firefox. This might be an option, but I'd really like to get around UA-sniffing somehow ...

[dlikhten]

~20% is better but still bad. Can we do better? I mean I would argue that above a few % max is already too much. A regular spinner image which can easily be generated and uses very little CPU, it would be wrong to have this "feature" and murder the CPU all in the name of a few bytes transferred.

I would say implement the setTimeout methodology for now, but I can't in good conscience ship this code to prod until the cpu utilization is super low.

http://neteye.github.com/activity-indicator.html

The demo page has 5 indicators and uses a fraction of the CPU as a single-indicator spin.js. BTW spin.js did not load in my FF beta for demo page so thats bad, no comparisons possible. Chrome's utilization was < 1% for the 5x activity-indicator vs 3% for spin.js on windows 7 x64.

Though even the other site has about 20% utilization of a single core when running 5x spinners. Which I assume would be about 5% on one spinner.

[glennfu]

I read in the jQuery 1.6 patch notes this line: "Additionally jQuery is now using the new requestAnimationFrame method provided by browsers to make our animations even smoother. We can use this functionality to avoid calling timers and instead depend upon the browser to provide the best possible animation experience." Is that something that can be taken advantage of here? https://developer.mozilla.org/en/DOM/window.mozRequestAnimationFrame is the link to the specific feature. Sorry if this is irrelevant, just hoping to help!

[fgnass]

@glennfu In my earlier tests requestAnimationFrame() resulted in even higher CPU usage due to the increased frame rate.

[fgnass]

BTW, when I view a GIF on http://ajaxload.info/ in Firefox, CPU load is at ~16%. Maybe this is related to one of these bugs: 595671, 645761, 484793. I'll try to reset my profile and check CPU usage on other platforms and in older FF versions.

[fgnass]

Under Windows XP Firefox 6.0.2 only uses 0-3% CPU so this seems indeed to be a MacOS-only issue.

[BYK]

@fgnass requestAnimationFrame has a second optional argument for WebKit based browsers where you give the bounding element for the animation which usually helps with performance. Have you tried using that? The behavior is documented on the related MDN page.