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!

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:

***Update: I’m already three steps ahead of this article. I have already received / analyzed the optimized JS in a later post. Please read all four articles on this topic before replying or your comment will be filtered. Thanks!***

Anybody notice a re-occurring theme here? Canvas performance on the new iPod Touch and iPhone 4G is laughable at 22FPS rendering simple animation. At least the Nexus One can muster up a decent 40FPS for basic canvas rendering. Flash Player 10.1 on the other hand, blows HTML5 out of the water running at 57FPS on the Nexus One! Let’s not forget to mention that HTML5 consumed TWICE the battery life as Flash for these tests on the Android. Unfortunately, Steve doesn’t want me to know the exact battery life on my iPod Touch so it wasn’t included in that part of the testing.

All of these test were done by benchmarking in browser performance. Native applications using AIR for Android yields even better performance but we’ll leave that for the day when HTML5 can export to an APK (native Android app).

Let’s take a peek at some live footage:

Frame rate comparison:

Keep in mind Flash Player 10.1 is relatively new. If Flash had been included with the original iPhone, you would have hated it. The new version, however, kicks ass. Would love to see some hacked iPhone Flash benchmarks to fill in the missing pieces on the above graph. If the iOS can’t render a little ball, HTML5 is going to be a hard sell for iDevices.

Why do we need 57FPS? Most web content targets 30FPS.The human eye really can’t differentiate after about 30FPS. Well, this is a single object rendered on the screen. Add some game logic, additional balls maybe a graphic and you’ll quickly find the 24FPS on the iPod dip down below 15. Having extra CPU cycles to do other things allows developers to target 30FPS when building games and animations.

Battery consumption after 10 minutes:

***Addition: The graph above is in percentage of batter drained after 10 minutes of animation during airplane mode (no cell or internet traffic to get in the way). A bit more crude than the first graph but I really didn’t want to sit around all afternoon waiting for my battery to drain. I’ll try to post some more battery data soon. The most important note is that Flash didn’t consume more battery than HTML5, which was counter to my initial hypothesis.***

This graph explains itself. Canvas consumes more battery power than Flash. It’s amazing that Flash can render something at 57FPS in half the battery power than it takes canvas to run at 40FPS.

Try it out:
HTML5 (JavaScript):
http://www.blackcj.com/blog/wp-content/jsdemos/BallBounce/

Flash (ActionScript):
http://www.blackcj.com/blog/wp-content/swfs/BallBounce/

Conclusion:
HTML5 will sit side by side with Flash. Gradient fonts, drop shadows, basic video and simple transitions are probably better suited for HTML5. When it comes to rendering display objects, animation and digital rights management for video, it would be silly not to use Flash. But wait Chris, HTML5 performance is going to get better! I’ll believe it when I see it. Adobe continues to raise the bar and it will be an uphill battle to catch up.

Graphs created using this tool:
http://nces.ed.gov/nceskids/createAgraph/

Afterthought:
I’m actually quite satisfied with the HTML5 canvas for Android. It will probably work for what I was planning to do. After the iOS exporter in CS5 failed to produce quality animation results, I was hoping for more from HTML5. Basically, I feel stuck having to code in Objective-C just to hit the iOS folks out there. This essentially ruined some of my plans for creating a game framework that runs Box2D cross platform. It basically made my purchase of an iPod Touch rather worthless. Unless Apple steps up I’m going to have to exclude iOS devices from my demos or re-code everything in a third language. The whole point is not to have to re-create the same code for every device in a different language.

Pop up Window Example:

(click on the link above to open a 200 x 300 pop up window)

Any JavaScript tag can be run this way. Try adding an alert right after the window.open script. Notice how they both execute. Yet another reason to ALWAYS validate your input fields when displaying htmlText. Nothing worse than somebody adding some inline JavaScript to your Flash form.

Resources
http://www.webmasterworld.com/html/3429895.htm
http://kb2.adobe.com/cps/141/tn_14192.html

What does this graph tell us?
Well, even through a recession, ActionScript job growth has held strong. Objective C on the other hand looks very unstable.

And this one?
Nobody seems to be able to make up their mind about how much to pay Objective C programmers. Is it worth more than HTML or not? Would you work in a development language that had the potential for a 50% pay cut if you lost your job?

http://www.hiten.net/wilberwind/wordpress/?p=826

How about this chart?
I would like someone to point out the web development language that died. Anyone? Oh wait... none of them have ever died! When somebody comes out with something better, the competition does the same. Not to mention that it took AJAX nearly ten years to catch on. As much as some people hate PHP, it is still around. As much as some people hate Microsoft, .NET is still kicking. As much as Steve Jobs hates Adobe, Flash is here to stay.

Do I hate HTML5 and think it will fail? No. I hope it succeeds. The reason I code ActionScript is because it is widely supported and cutting edge. HTML4 wasn't enough for me. When HTML5 has a 3D engine, physics support, frameworks, blogs of examples, full browser support, and a great IDE, I'll strongly consider it. Until then, please don't tell me I should look for a new profession.

*Update 02/02/2010 @ 7am in response to a comment below*

Analysis:
Perl seems to be holding strong. I wish the data went back further, was there ever a significant decline? They still have a pretty big market for jobs with a steady incline. Coldfusion jobs have not gone up but have also not really gone down over the past 5 years. That's pretty good job security for 'dead' languages.

Looks like Silverlight has seen nothing but positive growth over the past few years. Was it two years ago Microsoft and .NET developers where predicting the death of Flash due to Silverlight? Looks like there is enough market for both. If the web wants interactive maybe there is room for Flash, HTML5, and Silverlight to all grow over the next 5 years. Based on the data at hand, that would be my prediction.

Problem:
Let me start by saying SWC's are great. I've been using them more and more to include third party API's, utilities and assets. There is one problem, embedding a font into an asset in a SWC will override the internally defined fonts in a project. Why is that bad? Well lets say you have a static text field in your SWC using Georgia and a TextField instance in your Flex project using Georgia. No text will show up in your Flex TextField. Check out this example (notice it starts invisible):

SWC Text Embed Conflict:

(switch between MyGeorgia and Georgia fonts to see the disappearing text)

Full source code can be found here.

Solution:
Define your embed tags in ActionScript with a different fontFamily and fontName. So, if your font is Georgia than name it EmbedGeorgia. This will allow your TextField to reference the correct class definition. In my experience the SWC will always win if there is a conflict.

rather than...

It's that easy?
Yup.

What if you have two SWC's with Georgia embedded text?
Will they conflict with each other? Based on the example above the answer is no. Awesome!

What if my fonts are stored in a SWF file?
Than duplicate the above code but reference your SWF instead of the font in the assets folder.

Code that results in invisible text:

Swap out the Embed tag, update the TextFormat and you will be good to go.

Rant:

On the way to this solution I came up with a number of hacks that appeared to work only to break at the worst time. These hacks included storing a second reference of the font in the SWC (assuming you have access to the source), enumerating through the font list at runtime (which only fixes the problem in debug), and breaking apart the text into bitmaps (you don't want to know how long that takes). Rather than stop using SWC's I started to create more and more of them pushing towards an acceptable solution. This is what I ended up on. Hopefully it will save everyone some time and a little sanity

Problem:
Embedding transparent PNGs dramatically increases the size of your Flash, Flex and AIR applications. Photoshop and Fireworks dot not have any compression available for transparent PNGs (that I am aware of).

Solution:
Import your PNGs into Flash, give them a linkage id, and export the file as a SWF. Make sure to set your compression level in the publish settings (default is 80%). Using this method, I was able to cut the file size in half for a number of applications.

rather than...

It is also much easier to manage your external assets from a SWF. Designers can set up a nice slice sheet using the stage in Flash. Much easier than managing tons of small PNGs in folders everywhere.

Image Manager

In addition to using the SWF it can also be very useful to set up an ImageManager to serve out images to your application. This prevents having to change code in multiple places to update the same image reference.

Image Manager Class:

To access an image from the manager class just make this call:

Importing PNGs into Flash

And for those of you that need a refresher on importing PNGs into Flash and setting up linkage IDs:

File->Import->Import to Stage...

Right click on the image. Select 'Convert to Symbol'...

Finally...

Enjoy!

Disclaimer: It may be obvious but you must be using transparent PNGs in your app to see a decrease in file size Most of the apps I work on have lots of transparent PNGs!

Problem:
Flex can't do true cascading styles like HTML (for example a black play button)

Solution:
YES, flex can do cascading styles. It just requires a different approach. A programmatic approach. Don't worry, I assure you that even a non-programmer can pick this one up.

Lets dive a little deeper. Cascading styles refers to the ability to start with a button, style it into a black button then go a step further and make it a play button. First, create a button and use some CSS to style various properties of that button.

Simple enough, right?

Next we want a black button:

There it is. All the actionscript you will need. And to think it was all auto generated!

Actionscript Class Generation

Add the MXML and CSS:

Now we have a black button. This process can be used as many times as you want to continually inherit properties from another object. You could have a small, blue button with red text all styled at each level.

Lastly, we need to add the play icon:

Now we have a black play button. Add a stop, pause, and mute button as BlackButton's and they will all be updated when you modify the style for either the base Button class or the BlackButton class. Again, this tutorial is not very technical but the next two will be. This is meant to be the first step in bridging the gap between design and actionscript using Flex 3.

The number of comments I get on this post will exponentially increase the likelihood of part 2 coming out sooner

Sample

Source View

References:

The Woes of Flex

CSS in Flex is not real CSS at all

Adobe Bug Page