boostworthyisryantaylor

I’m flying out to San Francisco tomorrow for the Adobe MAX conference; it is certainly shaping up to be a good one! As you may have heard, attendance has just hit 5000 people; a new MAX record. If you are one of those 5000 people and you are interested in Pixel Bender, be sure to attend my presentation ‘Pixel Bender Unleashed’ on Monday at 5:00pm. It looks as if it is going to be a full house, so make sure and get there a little early so you can get a seat.

I will be covering lots of important facts about the implementation of Pixel Bender, not only for Flash, but After Effects and Photoshop as well. I also have some modest, practical demos that I will be sharing, as well as a few ‘extreme’ ones per say. My goal is for you to leave the presentation both educated and inspired to explore the use of Pixel Bender in your own pipeline.

See you in The City!

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

You probably noticed that I haven’t blogged for almost three weeks now. Part of that is due to the fact that I have been busy getting presentations ready for my upcoming trip to Costa Rica for the Schematic Tech Summit and also for the Adobe MAX conference in San Francisco this November. The other reason is because I recently began getting hardcore into a second development platform - native application development for the iPhone.

I have learned quite a bit this past month while working on a couple of iPhone projects for Schematic. Though the Objective-C syntax is definitely a bit weird compared to ActionScript, Java, etc., I have actually become rather fond of some aspects of it. Having said that, I was thinking about putting together a nice, long tutorial for Flash developers who are interested in getting started with iPhone development. Before investing a lot of time in such a tutorial, I wanted to get a feel for how many of you would be interested in something like that.

So if you are interested, please post a comment letting me know. Also, I am thinking about doing a video tutorial instead of a super long blog post. If you would prefer one over the other, make sure and leave that in your comment as well. Thanks!

Something nice that recently appeared in the Pixel Bender spec is the preprocessor symbol AIF_FLASH_TARGET. When testing under normal conditions, AIF_FLASH_TARGET is set to a value of 0. With Flash warnings enabled, AIF_FLASH_TARGET is set to a value of 1. Testing against this allows you to use methods that are not currently supported by Flash Player while testing in the Toolkit, but still produce a shader that is Flash compatible.

To better understand this, create a simple procedural shader such as the one below:

If you were to run that shader with Flash warnings disabled, you would have a 200x200 box with a RGBA parameter that sets the color of the solid fill. Now enable Flash warnings and run the shader once more. This time around, an error will be thrown telling you that only the evaluatePixels method is supported in Flash.

Now insert a statement that checks the AIF_FLASH_TARGET symbol:

Once again, try running the shader with Flash warnings on and off. Notice that no errors were thrown while Flash warnings were enabled. Also notice that nothing is being rendered in the display panel. This is due to the fact that the generated method is not being used. This is ok though, as use of the drawing API in Flash to create a shader fill will work just fine.

Now for the bad news - it seems that there is currently a bug with the Pixel Bender Toolkit in which the value of AIF_FLASH_TARGET is not set to 1 while exporting to byte code for Flash. Doh! I have already entered a bug for this issue, so rest assured that it will likely be fixed by the final release of the Toolkit. Nonetheless, I wanted to post about this functionality anyway since it is essential to creating shaders that work as desired in the Toolkit as well as in Flash.

This is a pretty big deal...especially for all of us that contribute so heavily to moving the internet forward. Comcast just recently modified its user agreement to set a monthly limit on bandwidth. Though their limit of 250gb may seem generous now, how long will that last before technology catches up and suddenly you find yourself paying extra money for more bandwidth? Time Warner and other cable companies are experimenting with this business model as well.

Unfortunately, this is only the tip of the iceberg. The next step is to offer various monthly plans for bandwidth (similar to those offered by cell phone companies). Worst of all, these plans will also include deals to have more/unlimited bandwidth for certain websites, but not others. For instance, a deal could be cut with Google stating that for X amount of money, the cable company will allow its customers to have unlimited bandwidth when using GMail, YouTube, etc. Think of this as the same type of model used by cable companies for cable TV; the more you pay, the more channels you get.

While you might be thinking to yourself "fine, if I have to pay more to continue using the internet as I please, then I will", that won't be the case for most people. Casual internet users will not be willing to pay more money and will also become very cautious of the amount of bandwidth they use. This could potentially result in a huge step backwards for the internet; something that none of us want. Lighter internet usage means less video, fancy Flash sites, etc. You get the idea.

This issue as a whole is known as net neutrality and is something that we all need to become very aware of and start fighting right now. The best thing you can do at this point is spread the word and make it very clear to congress that net neutrality must be preserved. Save The Internet is an organization that has a letter pre-written and ready for you to email to congress automatically; all you have to do is digitally sign it. I encourage you to take a few minutes out of your day to sign and send that email along, as well as pass this blog post along to your friends. This could have a hugely negative impact on our industry; we need to stop their greed before it is too late.

As I have mentioned in previous posts, I spent the better half of this year working on a cutting-edge Flex application at Schematic for the PGA Tour. The application is their official shot tracker and it is publicly accessible for free from the PGA Tour website. Since the application is only active during tournaments, which are typically every Thursday-Sunday, many of you probably haven't had the opportunity to check it out. Fortunately, the PGA Tour just released a demo video which demonstrates the application. If you are interested, here is a link to the demo:

http://www.pgatour.com/shottracker/demo/

Also, here is a direct link to the application itself:

http://www.pgatour.com/shottracker/home.html