boostworthyisryantaylor

The Flash Player team has made some changes to the way that versions are numbered/described. Instead of the old way in which something like 9.0.115.0 magically represented Flash Player 9 Update 3, the new system is as follows:

major.minor.bugfix.build

In other words, 10.0.22.36 reads as FP 10.0, bugfix 22, build 36. The build number is basically irrelevant to us; we should continue focusing solely on the first three numbers. Also, the bugfix number will have three variations; for example:

10.0.20.# - developer build
10.0.21.# - beta build
10.0.22.# - RC/GM build

I am really happy to see that they decided to move forward with this. It should be much easier to keep tabs on feature-specific versions and so forth from now on.

As you have no doubt probably heard, Adobe officially released Flash Player 10 today. I have a nice little quote on one of the Flash Player pages on Adobe.com:

Via http://www.adobe.com/products/flashplayer/action/

I am not sure how accurate this is, but I remember hearing that FP10 beta had a 60% penetration rate last month or something along those lines. While it may be too early to start targeting FP10 for large client projects, it is definitely time to get busy trying out all of the great new features if you haven’t already. On that note, if you have done any really cool experiments for FP10, feel free to share it with the world via a link in the comments section below.

Many of you have expressed concern regarding the Flash implementation of Pixel Bender using the CPU rather than the GPU like Photoshop and After Effects. A lot has changed since my first post on the topic of generic number crunching; though you can certainly refer to my previous post for reference on how to get started, I have some additional points that I would like to make clear:

1.) Compared to pure AS3, a Pixel Bender kernel will be up to X number of times faster; X being the number of CPU cores the machine it is running on has. It isn’t always a 1:1 performance gain though; I would say on average that a complex task will be around 3x faster than the optimized AS equivalent. Keep in mind that you are also working with 32-bit floating point values in Pixel Bender, where as in AS something like BitmapData is limited to only 8-bit uints per channel.

2.) Even if Flash had full GPU support, the CPU would still beat it out in some cases. A good example of this is when you are using a kernel to handle some generic number crunching. Reading back data from the GPU rather than just displaying it is a very slow process. The mindset that GPU support would be the answer to all of our problems in Flash is simply not true.

3.) Not every task will see a performance gain by moving calculations from AS to a PB kernel. In general, operations to a bitmap or bitmaps will almost always be faster, but in the case of generic number crunching, it depends on the complexity of the math taking place. Simply deferring your cross product calculations from AS to a PB kernel is going to be the same speed or even a bit slower in some cases. The biggest advantage to deferring your complex algorithms to a PB kernel is that you can avoid UI lag while the shader job is processing. This is due to the fact that the calculations are taking place on a different thread than ActionScript. Finding the right balance between AS and PB is simply a matter of experimentation and testing.

4.) PB rendering tasks are split up by row and delegated to each core on a multi-core machine. If the height of an input is one, only one core will be used. In other words, be smart about how you configure the heights of your shader jobs; more CPUs crunching your numbers means faster performance.

5.) There are limitations in the PB Toolkit that prevent you from exporting byte code with certain output types (currently, these problems revolve around limitations with GPUs). These limitations force you to either work with collections that are a width of a certain multiple or do some sort of filtering process in AS after the shader job has completed. The PB command-line utility that Adobe will be releasing soon addresses these limitations by allowing you to export byte code for everything that FP10 supports, thus alleviating the need to do workarounds.

As I have mentioned in previous posts, I will be covering all of this information and a whole lot more in my session ‘Pixel Bender Unleashed’ at Adobe MAX this November. Seats are starting to fill up, so if you haven’t already setup your MAX schedule you should definitely do that before you miss out on any of the big sessions that you wish to attend.

On a final note - I haven’t gotten around to doing the iPhone tutorial for Flash developers yet, but will be doing so this week. Look for a post on it soon!

One of the biggest problems that I have had with using MXML in the past was the inability to properly document MXML code as you would in a standard ActionScript class. Adobe recognized this limitation and is addressing it by adding new support to the asdoc tool. For more information and examples, check out the link below.

http://opensource.adobe.com/wiki/display/flexsdk/ASDoc+in+MXML