I’ve been working on a mixin to add animation to SproutCore views.
The current version only works for layout properties, and does not yet work for centerX and centerY properties (they used to work, but some of the performance optimizations have made it slightly more tricky—I’ll be adding it back soon, though).
I decided to see how fast the code was in different browsers. The tests were done using a test application which generated a specified number of views, and then, once per second, updated a “frames per second” display. The measuring is somewhat subjective, as I have to deduce, based on consistency (or lack thereof) in the numbers, what the frame rate actually is. For the most part, they were pretty consistent, but the WebKit browsers at really low numbers of views (and really high frame rates) could be quite inconsistent at times.
I ran the tests on two separate machines:
- Mac OS X Snow Leopard on MacBook Pro 15″ Core 2 Duo 2.33Gz w/2GB RAM. Lots of open programs, including iTunes. Not as scientific as would be optimal, but it is my work machine.
- Windows XP on Pentium 4 3.20GHz w/2GB RAM. Only the browser was open.
Browsers tested (note that my Firefox was OLD):
- Safari 4.0.3 for Mac
- Firefox 3.5.3 for Mac
- Chromium 4.0.223.3 (29380) for Mac
- Internet Explorer 8
- Firefox 3.0.1 for Windows (oops. Should have upgraded first. Remind me to update numbers on Friday)
- Safari 4.0.3 for Windows
- Chrome 3.0.195.27 for Windows
Here is the data:
Data collected during testing of the different browsers
That’s boring. Where are the pictures?
All Browsers
Even here, you can tell that Chrome and Chromium are the best performers for small numbers of views. However, for larger numbers of views, Safari on Mac was a very clear winner, running at 12 frames per second for 2000 LabelViews..
Predictably, Internet Explorer was slowest. I didn’t bother to run all the tests for it.
Windows Browsers
This chart shows only the Windows browsers. Again, you can tell IE is very slow. Chrome is very very fast. Safari is pretty good. My out-of-date Firefox is not always that much faster than IE; it will be interesting to see how Firefox 3.5 fares.
Notice the dip in performance for Safari at around 300? It briefly does worse than Firefox. It quickly levels off, though, and is second only to Chrome.
Mac Browsers
And, of course, the best for last. Note how we see the same dip in performance for Safari—though it does not dip below Firefox; it would have dipped below Chromium, were it not already below it. Again, though, it leveled out faster than Chromium.
I always wanted to do a performance chart, but now that I have… it’s a lot of work (about 57 or so data points there… each measured separately).
Question Is the difference between Safari and Chromium completely caused by Google’s V8 JavaScript engine, or are there a few other differences?
Tags: animation, browsers, javascript, SproutCore, Testing
Very impressive, and nice work. Since you’re using webkit transitions (where available) you might want to try animating -webkit-transform: translate3d(x,y,z) instead of the left/top/right/bottom (I just glanced at your code, so I think that’s what you’re doing). This has the potential to be much faster, since it’s hardware accelerated (in snowleopard Safari 4, at least).
Thanks!
Also, thanks for the suggestion; it is very intriguing, and I am tempted to experiment with it…
I’ll have to think over it. On the pro side, it will be GPU accelerated if possible; on the con side, when/if transitions themselves are accelerated through GPU (I’ve heard mention of this, at least), then those will probably be faster again…
This will be difficult to test quantitatively; I was unable to test the FPS of WebKit transitions, as I don’t control them (I disabled transitions for my tests). I’m looking for a way to test that (aside from by-eye, which has been my only way of judging transitions so far). Any ideas?
Thanks!
Hmm, not sure how you’d capture FPS for hardware accelerated transitions. The best I can think of would be to screen capture it and measure it, but most screencap utilities are locked to 30fps :/ There’s a bug (https://bugs.webkit.org/show_bug.cgi?id=23812) against the WebKit team to expose some sort of FPS debug information for hardware accelerated animation. I’m not sure how they might prioritize that, but hopefully it shows up at some point.
Alex:
I have a transform function in SC.View that will transform any layout into a Top, Left, Width, Height layout and back. You should just use that for the conversion to make your mixin simpler. Contact me on IRC or email me to talk about it.
Evin (etgryphon)
[...] Animation Layer I’ve been working on a mixin to add animation to SproutCore views. [...]
[...] Animation Layer I’ve been working on a mixin to add animation to SproutCore views. [...]
So, you took new Core 2 Duo 2.33Gz and Snow Leapord(most recent) for Mac and then compared it with 6 year old P4 and 6 year old XP ? And then you are publishing comparisons ? Please don’t compare Apple->Orange!
I was not intending to compare the Windows and Mac performance. I was wanting to compare browser performances relative to each other. That’s why I also split the two charts from each other.
I agree completely: the Windows and Mac speeds are not at all comparable.
[...] Animation Layer I’ve been working on a mixin to add animation to SproutCore views. [...]