boostworthyisryantaylor

Whoo, that was rough! My burn out seems to be behind me finally. I am catching up on emails slowly but surely and even managed to squeeze in a few blog posts this evening. I have been nose-deep in both Flash and iPhone apps at work, so I am feeling motivated to do that iPhone tutorial sometime soon. No need to give me grief, I am well aware of the fact that I promised it nearly four months ago.

By the way, if you missed my presentation on Pixel Bender at Adobe MAX last year, it has been posted on Adobe TV for your viewing pleasure. Apparently my crutch word is “uh”; I lost count of how many times I said it.

On a final note, my peers are pressuring me more and more into joining Twitter. People are losing the fight all around me (Mr. Doob, David, Grant). Should I follow suit and conform or hold strong?

Awhile back, I wrote a similar post titled Cure For The ‘Unable To Resolve Asset For Transcoding’ Compiler Error. Though old, the post continues to get a lot of hits, so I thought I would post another entry on a similar issue which you may have encountered.

Have you ever been working on a project and went to do a build, only to be slapped with a bunch of ‘Unable To Resolve (asset path/name) For Transcoding’ errors? Perhaps you are reading this post because it just happened to you and you have no idea why. Continue reading.

The reason this occurs is because you have some assets somewhere in your project that are now missing; whether it be because they were moved and their references in your CSS were never updated or possibly because they were deleted by mistake. Whatever the reason, they are no longer at the location specified in your CSS and that is causing the entire embed process to fail. The tricky part is figuring out which assets are the problems. Unlike the rest of errors, the actual problematic assets will read ‘Unable To Transcode (asset path/name)’. If you do not see any errors with this message in your Eclipse ‘Problems’ panel, it is because it only shows 100 errors by default and you may have many more than that depending on the size of your project.

To change this, click the little arrow in the top right-hand corner of the panel and select ‘Preferences…’ from the menu. In the pop up window that appears, find the line that reads ‘Limit visible items per group to:’ and change the number next to it from 100 to a larger value, such as 200. Repeat this process if you still aren’t seeing all of the errors. Once they are all visible, you should be able to find the errors which call out the assets that are causing the problem. Make the appropriate changes and re-build; your problems should be gone at this point.

If you have ever worked with the Flex VideoDisplay component, you are no doubt aware of the fact that its long list of conveniences come at the expense of some limitations and bugs. While the intention of this post is to cover a simple workaround for a few issues, I encourage you to share additional bugs and workarounds that you have had to implement in the comments below.

NOTE: Before getting started, I highly recommend that the minimum version of the Flex SDK that you target be 3.2.0.3958 due to a variety of video related fixes have been made in builds prior to this.

The issue that I would like to address is when you attempt to play a list of videos using the VideoDisplay component. What happens is that upon the 'complete' event being dispatched, you then update the component's 'source' property to reference the next video that you would like to play. Upon doing so, you will likely find that the component falls into an unresponsive state. More specifically the 'stateResponsive' property gets locked up with a value of 'false', rendering the object useless. If you do some Googeling, you will find posts that describe this occurrence and others that also occur as the result of race conditions internally within the component.

Fortunately, you can bypass this problem fairly simply by disabling a few things and creating a subclass of VideoDisplay. While you're at it, you can add an implicit getter and setter for toggling video smoothing; something that was unfortunately left out of the VideoDisplay API for some reason. Let's begin by examining a simple subclass:

All I am doing here is overriding the implicit getter/setter for 'source' and adding a call to the 'play' method each time the source it set. Now in your view, be sure to disable 'autoPlay' and 'autoRewind':

If you prefer, this could be handled in your subclass instead; for the sake of example, I am showing it in MXML. This is an important step though; it is the combination of the additions in the subclass and these two settings being disabled that will allow your video list to play one-by-one without encountering the bug.

Now, since you have a subclass ready to go, why not add access to the smoothing capabilities of the underlying VideoPlayer? To do so, you will need to gain access to the VideoPlayer instance by using the 'mx_internal' namespace. Simply add a getter/setter for smoothing to your class, then reference the example below for actually applying the changes:

Two birds with one stone, but a shame that any of this was necessary in the first place. As I mentioned earlier, if you have any other VideoDisplay workarounds for these issues or others and you would like to share them, please do so in the comments below.

Friend and local Flash enthusiast Kenny Bunch relaunched his company's site today. A lot of time and love has been invested in the Media Framework that he is offering; I definitely suggest you consider it if your company is in need of something super robust and well-written.

Congrats on the new site, Kenny!

You have probably noticed that my blog has been a bit lame the past month or so. The truth is that I am totally burnt out right now. It is sad really. I used to be such a machine; I could pull late night after late night and still stumble into work the next morning and be completely productive. Right now I am in this funk where all I want to do at night is sleep. For what it is worth, I do feel as if I accomplished a lot this year; most notably - six speaking engagements, two books, two native iPhone applications, and a sixteen month Flex project (started in August 2007). Needless to say, 2008 was quite the journey for myself and certainly the Adobe community as a whole. It always amazes me how much we mature as developers over the course of a year.

I plan on using the rest of this month to relax and refuel so that I can hit the ground running in January after the holidays. We have lots of new goodies to continue playing with, from Alchemy and Pixel Bender to Flash Catalyst and Gumbo...it is going to be an interesting year. I do plan on creating the iPhone tutorial for Flash developers that I promised back in September and maybe even picking back up on the next iteration of my animation library which has been gathering dust since the spring. Moses and I have been talking about collaborating on some interesting projects other than Go, so who knows what lies ahead.

Anyway, I just wanted to apologize for the lack of new content on here and rant about my current state of (unusual) burn out. I wish you all a safe and happy holiday season and look forward to rejoining you in 2009!

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