Blitting – Moving Bitmaps

Attempting to move display objects around during transitions can be very slow and choppy. Moving Bitmaps is much faster and can provide a smooth animation. When using this technique there are two things to consider; speed and memory.

Speed
Creating BitmapData from a DisplayObject is CPU intensive. Your user will notice even a fraction of a second delay in a transition. One solution to this is to predict where the user will go and store the BitmapData up front. For example, you know the first page they will hit after the splash screen is the login page. While the user is on the splash screen take a snap shot of the login page. Once they’ve arrive at a new view, take a snap shot of the previous and next views.

Memory
BitmapData is expensive. Caching to much BitmapData is the fastest way to slow down and crash your app. Make sure to call destroy on any unused BitmapData or re-use the same two or three instances. Another technique is to use a matrix to take a picture of the screen at half the resolution. You save both processing power and memory when doing this. During transitions on a device with high DPI this is often un-noticed by the user.

How much memory are you using? Use the profiler in Flash Builder to check for leaks and check out Memory Doctor on the iOS store. Version 5 of iOS is said to include app memory monitoring as well.

More information on blitting can be found on Jesse Freeman’s blog: http://flash.developerartofwar.com/

CPU vs GPU

There are plenty of sites that explain the precise difference between these two rendering modes. In the end how should you decide? Guess and check. With AIR 2.7 increasing the performance of CPU on iOS by 4 times, I’ve found that many of my apps perform better and use less memory with CPU.

Run your app with one than check the other. I found that before 2.7, my app ran better with CPU mode for Android and Blackberry but faster in GPU mode on iOS. Now that 2.7 is out, it runs better with CPU on all three. Selecting GPU mode can cause the application to consume as much as twice the memory. My app used 100Mb of memory in GPU mode and only 56Mb in CPU mode.

Avoid Transparency Like the Plague

Changing the alpha on display objects will significantly cut the performance of your app. Keep everything at 100% alpha and minimize the number of transparent PNGs you use. Similar to alpha, adding filters to your display objects will also decrease performance and increase memory usage. Is that drop shadow, beveled, semi-transparent text really worth it?

Destroy Your Display Objects

This part gets complicated. It can be beneficial to re-use display objects rather than re-creating them, for example in a list control. One thing to keep in mind is that these controls consume lots of memory. Keeping a ScrollPane, List, Grid and Picker around in memory all at once will crash your app. Re-use instances when possible but never keep around expensive components when your done with them.

There are plenty more optimizations that you can make in the world of mobile. The list above is what got me through my latest app for a client. Flex Hero handles some of the transitions and memory management for you and with AIR 2.7 it performs quite well. Please post any additional optimizations you’ve found helpful when building mobile apps with AIR.

Problem:
By default, the Windows 7 notification system prevents software products from making changes to your computer. Normally applications would prompt you for access but in many cases Adobe products fail silently.

Solution:
In some cases you can right click on the application and select to run as administrator. This only fixes a handful of issues though. To completely resolve all of the issues you’ll need to disable the pesky notifications within Windows 7 all together. To do this, open your control panel, click on User Accounts and Family Safety, select User Accounts, click Change User Account Control settings and finally drag the slider down to the bottom. You will need administrative access to do this.

Keep in mind this change will allow all applications to make changes to your computer without your consent. In my opinion, this is a small price to pay for working software.

Enjoy!

List of known conflicts:
>Dreamweaver unable to install HTML5 extensions during auto update.
>Extension manager unable to install any extensions.
>Flash Builder unable to install plug-ins.
>Acrobat 9 Pro upgrade from 9.0 to 9.2 fails to update.
>Distiller Print to PDF fails in all versions.
>Any others?

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:

Sample Canvas Code:

Sample SVG Code:

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.

You'll notice how we need two technologies to make this work. CSS3 performs great on my iPod Touch but doesn't work correctly on the Android. Want to view the Apple HTML5 demos? You'll need an iOS device. Android doesn't render any of the 3D transformations, typography or actually most of CSS3 in general. Will they fix this in the future? They better. Can you rely on CSS3 today? Not unless you're targeting iOS devices. When targeting Android for interactive content on the web, Flash still excels. Prove me wrong, build an HTML5 demo that works great on my iOS and Android device. I'll gladly share it with the world. For now, we have to put up with these ridiculous 'browser wars.'

Conclusion:
Use the best tool for the job. Don't make recommendations to clients without appropriate testing. If the project team is testing on an iOS device and the client has an Android who will suffer? My recommendation at this point is to code in Flash with a CSS3 fall back. Why not the other way around? Because Android technically 'supports' it and will render junk instead of correct content.

Link to the banner ads:
http://dev.sencha.com/deploy/css3-ads/

Lest We Forget, Ignorance:

Stay tuned for more comparisons on use of technology on mobile devices. I've found some very interesting data revolved around canvas performance on mobile devices. If you'd believe it, size does matter. Quantity of pixels that is. Check back tomorrow to find out more!

The Good:
Same code works on both devices!
Develop iOS apps on a PC.
Performance is good for simple animation and logic.

The Bad:
Box2D tanks through the exporter even with GPU acceleration, 17fps iOS vs 30fps Android.
File size is crazy big, my demo went from 3KB to 7MB.

The Ugly:
Registration for iOS development is a pain in the ass.
Exporting from Flash for iOS takes significantly longer than Android, minutes instead of seconds.

General Observations:
Colors differ slightly between the devices, iOS is lighter than Android.
Resolution through the exporter is currently locked at 480 by 320, which will hopefully change soon.

Summary:
The exporter works well for simple applications but don't expect to get real life physics. Performance on native AIR for Android is significantly better. The savings you'll get from developing once and deploying to multiple devices is HUGE. Just make sure your expectations are on par with actual performance or you'll be re-coding in Objective-C.

Turning on GPU Acceleration within AIR for Android:
Open the application descriptor XML file associated with your project. Edit the render mode to include gpu instead of auto. The hardware acceleration drop down within the publish settings does not currently modify this property, you need to set it manually.

Using cacheAsBitmapMatrix:

Using this code actually flipped my asset vertically on the stage. To correct this I modified the asset vertically within Flash. Using the cacheAsBitmapMatrix significantly increased the performance of the application.

Summary:
Using Box2D, the GPU and cacheAsBitmapMatrix will allow developers to create high performing games with realistic physics. These applications will soon be distributable across multiple mobile platforms. What are you going to create?

Not noticing improvement when selecting GPU? It's because there is a bug in the current pre-release packager for AIR on the Android. Luckily there is a quick work around.

The instructions are clear: add gpu to your descriptor file. Unfortunately Flash re-writes this file EVERY time you open the Air for Android settings window! Selecting the drop down in the Publish Settings also does nothing. So how can we enable hardware acceleration?

Create your project. Open the Android Settings to auto generate the descriptor file. Close the Android Settings window. Open your descriptor file. Add the code above. Save and close the descriptor file. Make that file READ ONLY. Open the Android Settings window again and select publish.

I went from an idle of 30 fps up to 120 fps and active usage from 22 fps to 30 fps. AMAZING difference when you can actually select to use it!

The touchable framework can be used in combination with applications that use keyboard controls which makes it compatible with the multi-screen initiative. Stay tuned for more demos!

Problem:
Developers are asked to complete 'project management' tasks on a daily basis. Many do not have the background to accurately complete the tasks, leading to problems down the road. Are you familiar with ROM estimates? Earned Value Analysis? If not, your walking down a slippery slop.

Solution:
Follow these basic techniques to add confidence to your estimates. Use quantitative measurements used by the best project managers to answer the dreaded percent complete question. Understand what your project managers are attempting to track in order to accurately transfer knowledge on key project elements.

Estimating

Let's start with estimates. I'm making the assumption that you, or someone else has, already done the business analysis for the project. You've got a rough idea of what the client wants. Maybe a quick phone call or piece of paper on your desk. Now, in the middle of your already busy day, you need to come up with a number. A number that may come back to bite you in the ass. So what do you do? Well, you've got three distinct types of estimating: ROM estimates, intermediate estimates and definitive estimates.

ROM Estimates:
For when you need to qualify a client. They are + or - 50% of the actual number. Mostly just to filter out the clients that are trying to waste your time. On small projects make these quick. For large projects, you really should make the client pay. Come up with a quick list of items required for the project. For example, a video upload / player:

Controls
Authentication
Backend processing
Video playback
Pretty Stuff
QA
Project management

Next, identify each as small, medium and large. Controls would be small, authentication medium, backend processing and video playback large and pretty stuff medium. Assign a number to small, medium and large. Let's say 4 hours, 8 hours and 12 hours. These numbers are gut feelings and should consider the type of client. Are they an agency that want's everything perfect? Or a small company that wants something to work? After that you assign the hours to the tasks and send it back to your project manager. Don't over complicate a ROM estimate. It's just a ballpark. Make sure the client knows this! You would be surprised at how accurate these quick estimates are compared to those that people spend days on.

How do I know my ROM estimate is within the ballpark of + or - 50%? I've got a trick for that. Ask your co-worker to re-estimate, right? Wrong! Developer time is expensive. You can't re-estimate everything. If you feel confident with another developers estimates just show them your stuff. If they like it than your good to go. Don't know if this developer is even paying attention? Change your estimate by greater than + or - 50% and see if they catch it. Quick and easy way to qualify a fellow developer without them knowing. If they catch it than they are good for future use, if not than go to someone else. Confront them about it at your own risk...

Intermediate Estimates:
The client chose you, for some reason or another. Probably because the sales person sweet talked them into it and dropped your estimate Now what? Take that ROM and turn it into some tasks? NO! Worst idea ever. You just took something someone spent so little time on that it's worth + or - 50%. Turning that into an estimate is like walking up to a hungry bear. You just don't do it.

OK, so what's next? Re-estimating! Seriously. You need to talk with the client for an hour, I know it sucks. Make sure you understand what's going on. Hopefully you have something that resembles a design at this point. If not, I feel for you. Create a new list of defined tasks for the first 20 - 40% of the work that are all less than 20 hours. Ballpark the rest, intermediate estimates are + or - 30%. Why not estimate it all in detail? Because projects change and the last 60 - 80% will be different than you think. Based on your metrics from the first 20 - 40% you can accurately estimate the rest. Metrics??? WTF are those? You'll have to wait till the next section. Now you have a list that looks like this:

Seek bar - 2 hrs
Play / pause buttons - 2 hrs
Volume control - 2 hrs
Database creation - 1 hr
GUI for login - 2 hrs
API for authentication - 2 hrs
PHP configuration - 2 hrs
Video processing - 8 hrs
Video playback -12 hrs
Fade on playback - 2 hrs
Easing for controls - 2 hrs
QA - 15% of total
Project management - 10 to 20% of total based on your metrics

Now you have tasks. We are going to ignore the definitive estimates because they generally aren't worth the time to create. Of course, your project manager says no, it won't take 20% of the budget for PM time. You than, very nicely, pull out previous project metrics that show otherwise. Show them data in their own language that shows PM time DOES take up that percentage based on statistical data. Don't be mean about it. Just bring it up. Then, if the project goes over due to the drop in PM time cause they didn't believe you, than you have something to back it up with. I can't tell you the number of times I've been on a project that had developers working UNDER estimates but PM time (meetings and status reports) took up way too much time causing the project to go OVER budget.

Whew. Done with the basics on estimating. For more details you'll have to wait for my book

Project Tracking

If you don't know what Earned Value Analysis (EVA) is, your leading unsuccessful projects. How do we know where the project is going wrong? And how do we get it back on track? Let me propose a situation for you. A plan flying from Minneapolis to Mexico. It's estimated to take 4 hours. After two hours your approximately half way through your fuel. Are you on track? Not enough information! What to you mean? Well, your assuming the plan is getting the estimated MPG. What if a strong headwind has set you back? Thinking about projects in two dimensions will lead to failure. Are you getting the proposed value from your estimates? Assuming you created a semi-decent task list you'll end up with this:

Seek bar - 2 hrs estimated (3 hours actual)
Play / pause buttons - 2 hrs estimated (4 hours actual)
Volume control - 2 hrs estimated (3 hours actual)
Database creation - 1 hr estimated
GUI for login - 2 hrs estimated
API for authentication - 2 hrs estimated
PHP configuration - 2 hrs estimated
Video processing - 8 hrs estimated
Video playback -12 hrs estimated
Fade on playback - 2 hrs estimated
Easing for controls - 2 hrs estimated
QA - 6 estimated
Project management - 8 estimated ( 6 actual)

Only 16 hours into the project an you already know it's off track. We are hitting our development estimates at 166%. At this rate we be way over budget. These numbers are incredibly accurate at forecasting the future. Unless the estimator really messed up, this project is way off track. What do we do with this data? Tell the client NOW! Let them cut a feature, increase the budget or simplify designs before you've capped the project budget. Trust me, they will appreciate it. I've never known a client to get angry after 5% of the work is done. If you wait till 100% of the budget is spent your SOL. Earned Value Analysis is the single most important project metric to track and it can be done with minimal effort, if tasks are created accurately. There are an endless number of combination's for this metric, for this example we are covering one. Again, you'll find more in my book.

That's it right? Let's do one more quicky before we leave.

Lessons Learned

It can be painful to look back at projects, especially un-successful ones. This MUST be done in order to improve the success of future projects. A few hours of review can save hundreds of wasted hours in the future. Correctly tracked EVA can show you where projects were under estimated. This article is for developers so I'll rip into PM's one last time. After tracking your time in meetings, calls, and reports if your PM time exceeds your estimates than there are a few options. Hang your project manager... no, wait this article is about working with them. Scratch that. Instead find opportunities to cut down on hours. Did the whole development team really need to sit in on that 2 hour call? Does the client really need a report every Friday? If so than you need to bump up your estimates! Really though, just knowing whats been over estimated will save time in the future. Joe keeps under (or over) estimating video players. Well maybe somebody should tell Joe? Sounds simple but without tracking how will he know? Are you tracking the results of your estimates?

Summary

Knowing the basics will help you. Unfortunately this is only scratching the surface. I keep hinting at my book in this article. It will contain some of the detail that I was unable to include in this post. There just isn't enough room in a blog post. For an even more comprehensive list of information please Google these topics. This is nothing new. Just things I've found to be new to most interactive project managers, designers and developers. Spread the word.

Resources:
Estimating Article (Pretty self explanatory.)

Earned Value Analysis on Wikipedia (I know, it looks scary. Trust me. If you can code, you can figure it out.)

Chris Black worked as a part of the project management office at Travelers Insurance. He worked to create a comprehensive list of best practices for project managers. Chris than went on to work as a developer and later as a senior developer at Sierra Bravo (a.k.a. the Nerdery). At the Nerdery he lead a number of successful projects using the metrics outlined above. Chris will be including these topics along with more technical items in his book which will be released in the second half of 2010.

Problem:
The added security in Flash player 10 requires user interaction prior to download. This can be a pain if your server processes the image and returns a URL forcing the user to click AGAIN to download it. Who wants to click twice to download an image?

Solution:
Cut out the middle man. Don't save the image onto the server, just use PHP to post it back to Flash. In one line of PHP code you can seamlessly download the image from Flash and with only one click from the user! No white windows flashing, no files written to your server and no headaches for the user.

Try it out!

(draw a picture above than click on the download link!)

Full source code can be found here.

The ActionScript side of things is less than 50 lines of code:

And the PHP is only 1 line!

Did I mention the final file size is less than 15KB? Oh, and if you really want a copy of the image on your server, just add some code to the PHP. I'll be creating another blog post soon on round trip imaging that will include a number of operations together into one utility class.

Happy image creation!

Resources:
Saving Images From Flash

Saving Flash Graphics