Mobile development and IoT
I’ve always heard good things about FITC Amsterdam and after attending FITC San Francisco, I had to add it to my list for next year. The speaker line up looks phenomenal with over 50 presentations during the 2 day / 2 night conference. Get inspired in one of the coolest cities around the world. Check back for some live blogging during the event!
March 8-9, 2011 Amsterdam, NL
2011 is nearly here, make sure to grab your early bird tickets before they sell out!
This newer, more complex, animation validates that canvas does not perform well across platforms. Using SVG we can achieve similar performance to Flash when but SVG does not currently work on the Nexus One. Overall conclusion: when displaying animations or content with lots of motion, we need to have two implementations until either iOS supports Flash or until Android supports SVG.
Thanks again for all the submissions!
Flash and SVG Outperform Canvas:
Results:
Canvas Demo:
http://www.blackcj.com/blog/wp-content/jsdemos/BallBounce/eb.html
Flash Demo:
http://www.blackcj.com/blog/wp-content/swfs/BallBounce/box/index.html source code
SVG Demo:
http://www.blackcj.com/blog/wp-content/jsdemos/BallBounce/ebsvg.html
Conclusion:
The new web standards are not mature enough to display animations or interactive content across browsers and platforms for mobile devices. I anticipate this to change within the next couple years (maybe sooner?) but for now, we are stuck implementing interactive content using more than one language. Both Apple and Google should get their act together and support both Flash and SVG. This demo shows that BOTH are ready for the mobile world. The only cross platform solution, canvas, does not currently perform well enough to use for animations and interactive content on mobile devices.
Sample Flash Code:
_canvas.graphics.clear(); _canvas.graphics.beginFill(_red<<16 | _green<<8 | _blue); _canvas.graphics.drawRect(0,0,_width,_height);
Sample Canvas Code:
ctx.clearRect(0, 50, _width, _height)
ctx.fillStyle = 'rgb('+_red+','+_green+','+_blue+')';
ctx.fillRect (0, 50, _width, _height);
Sample SVG Code:
_square.attr({width:_width, height:_height, fill:"#"+RGBtoHex(_red, _green, _blue)});
Notice:
Please keep comments constructive. I approve almost everything, however, really appreciate the people that take the time to understand what’s going on before posting or trying to improve the code. 98% of the code optimizations from the last demo completely missed the point of purposefully redrawing the whole screen to compare performance. They were still good submissions, just not for the context of this comparison. This demo was engineered in response to those people and to include SVG.
Interested in optimizing your JavaScript code with canvas? I received a couple great optimized JavaScript implementations for my ball animation where I slated Flash vs Canvas. We’ll keep Flash out of this discussion for now, as it appeared to cloud some of the points I was attempting to get across. Don’t worry the Flash optimizations will come soon. Right now, let’s take a look at some canvas implementations.
First and foremost, I want to shout out a big thanks to the two submissions I received. Both David Wolever and John Bates took time out of their day to provid demos which perform much better than mine on mobile devices. As we run through this code, keep in mind the demos I created where using the EXACT same re-draw code in AS and JS. In order to fairly slate these optimizations against Flash, the ActionScript code should also get the opportunity for a makeover. There hasn’t been a single Flash developer that has thought my code was efficient. I was going for equality over raw efficiency but we’ll cover that another day. All of my results below are running the demos on a brand new iPod Touch.
First let’s take a look at David Wolevers code:
The key lesson here is that size matters. Additional testing showed that canvas performs better at 300×300 resolution (40fps) than it does at 500×500 resolution (22fps). Unfortunately the reverse is true and bumping up to 450×800 churns down to 17fps.
What is it about David’s example that performs so well? Actually, it’s quite genius, only clearing and redrawing the square of the canvas that changed. Essentially he follows the ball and only erases and redraws the ball. This is a great technique for optimizing, however, not very scalable. It takes our performance metrics at 500×500 and really measures performance redrawing 50×50. With one ball this is a great solution but with many balls, some clouds, and a background this technique will not work.
This technique is something that I hadn’t even considered doing and was a great submission. We’ll be doing some more scalability testing later showing how additional objects effect this implementation. Thanks again for the submission!
Next we’ll take a look at John Bates code based off of work by Kesiev:
This code rocked on my iPod touch at 47fps with 4 balls. He also rebuilt this demo using object oriented programming techniques and was able to get a consistent frame rate of ~39fps with up to 5 balls. The updated demo can be found here. Very interesting that object oriented code has such a dramatic effect on performance. It does also suffer from the same performance vs. size and runs at about 31fps at 800×500.
A bit besides the point but is there anyone that can tell me why this demo runs at 20fps in IE9 beta on my desktop? Might very well be an IE9 bug but they definitely tout the great performance of new standards. Overall John takes home the gold on providing a scalable demo that runs with 39fps at 500×500 pixels on my iPod Touch!
Conclusion:
We have had a couple great submissions and I would encourage those who have created code in SVG, CSS3 and canvas to send your demos my way. Overall, if you are creating small resolution animation canvas isn’t a bad choice. At higher resolutions though, it tends to bog down the phone and performance suffers. The good news, I have some great code to work with and am excited to start integrating some of these improvements into my JS canvas Box2D demo. Thanks again!
OK, I promised to leave Flash out, but… the question you should all be asking right now is: How does Flash performance differ by pixel resolution? Does it suffer from the same short comings as canvas? If you’d prefer not to know the answer please stop reading now.
For those of you who want the answer:
The flash demo runs at 57FPS at 800×800 resolution on my Nexus One. More on this at a later date, maybe tonight, maybe tomorrow but for sure by Wednesday. Keep checking back for more comparisons on mobile devices!
After additional testing, Flash 10.1 still consumes about half the battery of the HTML5 equivalent in the browser on the Nexus One. This time running for 30 minutes, instead of 10, the canvas demo consumed 12% battery and Flash 7%. Arguably this is only a 41.66% difference but you get the point. Want to reproduce this test at home? Here are the steps that I went through:
Procedure:
Navigate to the desired demo to test so it’s cached in the browser
Close the web browser
Turn off all radios and put the phone in airplane mode
Set the brightness to manual and turn it all the way down
Set the screen timeout to 30 minutes
Charge Android to 92% power (or whatever baseline you’d like)
Unplug from the power and open your web browser
Leave it for 30 minutes
Close the browser and observe the battery power level
Repeat for other technology
Demo used:
HTML5 (JavaScript):
http://www.blackcj.com/blog/wp-content/jsdemos/BallBounce/
Flash (ActionScript):
http://www.blackcj.com/blog/wp-content/swfs/BallBounce/
Results:
Both of my 30 minutes tests started at 92% battery power. After 30 minutes running the canvas demo, the battery was drained to 80%. The same amount of time running the Flash demo landed at 85%.
Conclusion:
After running both 10 and 30 minute tests with both technologies, I feel quite confident in the results. Flash is consuming significantly less battery and performing better (57FPS vs 40FPS, see previous post). Keep in mind that with both of these technologies mobile browsers currently hijack multi-touch and mouse move. When coding interactive content for the mobile web there is a lot to consider but don’t assume that HTML5 canvas is the answer. I would expect better results once HTML5 has matured but my bet is that by that time Flash will be running even better. For the best performance use native applications for interactive content and keep the mobile web simple.
Now what?
This is actually getting quite complicated. CSS3 transitions work great on iOS but not so hot on the Android. Canvas works good on the Android but kills battery. The iOS performs horribly right now with Canvas. Flash works great in the web on the Android but not at all on iOS. Of course, a picture is worth a thousand words:
