Flash and Flex, bridging the gap

This post is a followup of my previous post regarding Flex and Flash. Although this is a followup, the focus has changed in parallel with the internal functionality and focus of Flex Builder and Flash. Back in august 2007, Flex and Flash existed in two different worlds, this is still the case, however now there are bridges between the two worlds.
As a developer, Flex (Builder/Eclipse) is a tool far superior to the Flash editor from my point of view. But when it comes to flexible design, Flex Builder still brings little to none to the table. And as far as my understanding of Adobe strategy goes, this is done intentionally. Flash should be an animation and design tool, whereas Flex Builder focuses on the developers. Adobe does intentionally try to separate the two..smart move!

What Adobe has done to amend for the intentional wedge driven in between Flash and Flex, is to create ways for developers to remain in Flex Builder while "importing" design created from within Flash. This is done trough bridging tools like the Flex component kit and the Flex component templates. This enables designers to stay in Flash(or any other CS product), using tools familiar to them, creating the design to be implemented via Flex. This approach to creating rich interactive content is much better than the old one involving big ass .fla files and no code help what so ever(almost). The snag is, when Adobe decides to change the approach of the designer developer workflow, change is also forced upon a bunch of Adobe/Macromedia users. To change their entire workflow may seem as a daunting task for many designers and developers. However this change is a change for the better, it's just a matter of dropping the conservative mindset.

As of now, the Flex Component kit is the best way to prepare for the real transition in my mind. You can of course go ahed and do lots of CSS styling in Flex builder, not a good idea unless there's only one person working on the project, as Flex builder is needed to see the design as a whole. The real transition is of course the introduction of FXG, the new interchange format making it possible to do full designs in CS products, add interactivity in the upcoming Flash Catalyst, then do the development in Flex Builder. In this way the different tools will keep their strengths and not worry about unrelated functionality, Flash becomes a design/animation tool and Flex a development tool exclusively. Like the current workflow of movie editing suites like FinalCut Studio, you will be able to use the FXG format to pass files back an forth between the designer and the developer, maintaining the focus, never worrying about stuff outside your field of your expertise. This is a long awaited and a big step for Adobe. Along with AIR, this move will in my opinion reinforce the FlashPlayer status as the goto(pun intended) technology for cross-platform interactive content and development.

Optimizing Flash performance

Introduction
As Flash designers and developers get a hold of even more advanced tools and scripting languages, the need for performance considerations within flash projects become ever so apparent. Lately I've seen people complaining about flash apps that bug down their CPU and memory when visiting sites containing flash media. I see this problem as two parallel problems.

1. Sites relying on advertisement (often flash banners) try to cram a gazillion banners and ads into every nook and cranny available on their site. This is simply greed, a condition for which I can offer no cure.

2. The Flash editor has been an animation tool for quite some time. As a result, things common to other development platforms, like performance optimization, has not been and still isn't a priority in most Flash projects. However, this has started to change, something I will try to contribute into trough this post. So, let's get it on...

General optimization

• WMODE. First of all, if you don't have an amazingly good reason for using it, do not use wmode! In short, wmode is used to make the background of the swf file become transparent. Wmode will render the swf unreadable to screen readers, force the swf to run when on a hidden tab and make the content of your swf to render much more slowly than in normal mode. Read more about this (Tinic Uro).
• Vectors and bitmaps. If you are animating a complex static vector, that is a vector that does not change it's content, e.g. a rectangle, then use the «cacheAsBitmap» property or simply use a bitmap instead. Let's say you are tweening a vector shape across the stage. The Flash-Player(FP) will have to recalculate all the vectors in the shape for every frame. For complex shapes, this will take up a lot of CPU cycles. With «cacheAsBitmap» turned on, the FP will calculate the vectors once, create a bitmap and re-render the bitmap instead. But do note this!! For vector shapes that are changing, not static, like lines that are constantly moving inside of a movieclip, if so..do not use «cacheAsBitmap». The reason for this is that FP now have to re-render both the changed vector shape AND create a new bitmap for every frame. So «cacheAsBitmap» is only good for static vector shapes.
• MovieClips. Not every shape needs to be a movieclip. If you need frames, you do need a movieclip, but if not, use a sprite(in ActionScript) or a Shape in the editor. Shapes does not have mouse and keyboard events and leave a much smaller memory imprint than MovieClips.
• Alpha. Crop your artwork instead of using big ass areas of alpha channel. The FP do render the alpha channel areas even if you cannot see them.
• Alpha video. A flv video encoded with an alpha channel using the On2Vp6 codec is about 4 times more complex to decode than one without the alpha channel. FP do not support alpha using H.264. Read more.
  

ActionScript optimization
This section is on ActionScript 3 only and can get somewhat technical.

• Strong typing. By typing your variables and functions the performance gain is substantial, in general 10 times faster. In AS3 the byte-code produced by the compiler actually changes based on typing. Also, strong typing makes it much easier to debug your app as the compiler will give more accurate debugger results. More on this.
• Numbers. Even though strong typing is quite easy to do, it's not always clear as to what type is the most efficient one. For numbers the «int» type is the speediest of the bunch, however «Number» does not lag far behind. However, it's smart to use «int» for iterations and situations where you are working on integers only as this will make debugging more effective. But do avoid «uint», unless you really need it. The «uint» type is a turtle compared to «Number» and «int». More on this here.
• Local variables. If you are going to access a variable more than two times, store it in a local variable first. Local variables are faster because they do not require a lookup into objects. E.g:
  var fName:String = person.firstname;
if(fName == "jim" || fName == "jill")
  is faster than
  if(person.firstname == "jim" || person.firstname == "jill")
  
• Data binding. Binding in Flex is a valuable and efficient way of handling data, however bindings do take up memory and they are general type. In other words bindings don't know what part of the data that will change, therefore all the data needs to be watched. If you are going the access the data only once or twice, it's better to do an manual assignment in code.
  

That's all folks.. be sure to check out the links as well.