agitcraft

I managed to complete my last minute registration for AdobeMAX yesterday and even managed to sign up for some sessions. Here is my tentative schedule for tomorrow morning:

• 8:00 am – 9:00 am: Deep Dive into Mobile Development with the Flex SDK
  • Learn how the next version of the Flex SDK will enable developers to easily create applications for the desktop and mobile devices. This session will show you how you can use the new mobile features in the SDK together with familiar Flex concepts to build mobile applications. You will learn about the new mobile-specific components and capabilities being added to the Flex SDK, as well as learn tips for optimizing both the design and performance of your application as it works across different devices.
  • Speakers: Glenn Ruehle, Chiedo Acholonu

• 9:30 am – 10:30 am: Deep Dive into Flash Player Rendering
  • Dive deep into the Adobe Flash Player renderer with Lee Thomason, Flash Player architect, and see how to optimize the rendering performance of your applications. Thomason will cover mechanisms like the display list, text rendering, shaders, GPU hardware acceleration, and exclusive features coming in a future version of Flash Player. After this session, Flash Player rendering will no longer be a mystery.
  • Speakers: Lee Thomason

• 11:00 am – 12:00 pm: Creating Testable Flex Applications
  • Join the expert team responsible for the FlexUnit 4 framework as we look beyond writing unit tests toward the real issue: writing testable Flex code. We’ll examine the techniques needed to change functional but untestable code into cohesive classes whose functionality can be assured continually through automated unit testing. If you ever needed to know how to architect testable Flex applications, this session will prove invaluable.
  • Speakers: Michael Labriola, Jeff Tapper

• 1:30 pm – 2:30 pm: Performance Tips and Tricks for Flex and Flash Development
  • Investigate Flex application development from a performance perspective and learn techniques to improve and optimize your Flex and ActionScript code. Join members of the Flex engineering team as they identify common performance pitfalls that new — and even advanced — developers run into, and share best practices for creating the most optimal Flex and ActionScript applications. We’ll share tips and tricks for desktop and mobile development, as well as methodologies to identify and fix problems areas during development.
  • Speakers: Ryan Frishberg

• 3:30 pm – 4:30 pm: Having Fun with Layouts in Flex 4
  • Join Enrique Duvos, Adobe Flash Platform evangelist, as he introduces you to creative layout techniques leveraging the new Flex 4 SDK component model and layout architecture. You’ll learn how to develop sophisticated layouts from both a technical and user experience point of view. Topics will include assignable layouts, transformations, 3D, visual orchestration, and more.
  • Speakers: Xavi Beumala, Enrique Duvos

• 5:00 pm – 6:00 pm: FutuRIA: The Convergence of Rich Internet and Enterprise Applications
  • Hear top design professionals explain how to unlock new value hidden in complex enterprise systems through the expression of user-centric goals in design patterns. You’ll learn how Adobe is converging solutions, platforms, and tools to help you better serve your customers or constituents by delivering great experiences. This session equips you with business cases as examples of current cultural shifts, as we share our user experience vision, some technology sneak peeks, and a vision for the future of enterprise applications.
  • Speakers: Ben Watson, Andy Mulholland, Matt Butler, George Neill, Tadeusz Chelkowski

As you can see, I have a full day lined up for me despite being quite late to register and prepare. I’ll try and blog and tweet about each of these events as the day goes by.

I’d like to take a moment to draw your attention to a very useful class that’s been around for some time, but that I’ve never really bothered to use: flash.system.Capabilities. It gives you all kinds of useful information about the environment your SWF currently resides in. I’ve got an example below.

The SWF above (with any luck) should tell you whether or not you’re running a debug version of flashplayer, who the manufacturer of your flash plugin is, what operating system you’re running, what player type you’re using (should be plugin on this page), and what version of the flash player you’re running.

The code for the demo is as follows:

field_version.text = Capabilities.version;
field_player.text = Capabilities.playerType;
field_os.text = Capabilities.os;
field_manufacturer.text = Capabilities.manufacturer;
field_debugger.text = Capabilities.isDebugger.toString();

If you download the files for this demo here and run the SWF on your local machine, you should see a different value in the player type field.

The player type is the most useful piece of information to me. In theory you could use it to load different data or behave differently in general depending on whether you’re viewing your SWF in the Flash IDE or on a webpage, without having to add your own obnoxious boolean “debug” flags.

Today, as happens once in a blue moon, I was presented with a stack of flash banner ads along with a request that they be squeezed under a 50k file size limit. If you’ve ever worked on banner ads you’re probably familiar with these sorts of limitations, as well as those placed on duration and the use of rich media. You may also be aware of how frustrating and difficult a task it can be to squeeze banners, with all the aesthetic demands placed on them, under these arbitrary size thresholds.

After several years of dealing with these issues, I’ve come up with an array of tips and guidelines for reaching the file sizes that ad networks demand. Some techniques are more effective than others. Many of them may compromise the aesthetic integrity of the files you’re working with so it’s best to use a mixture of these strategies to suit your needs.

I’ve prepared a sample banner in a standard size (300×250) to use as an example. You can download the initial source files by clicking here.

We have what seems to be a very simple banner animation. Several pieces of text fade or slide into view, and bubbles are dynamically placed on the stage and flown from right to left. A number of different fonts are used (all variations of HelveticaNeue) and the image in the background is crisp and clear. It may not seem like it’s very complicated, but this SWF is actually 1.6mb. How can that be the case, and how can we fix it? Let’s look at a couple things we can change.

1. Embedded Fonts

The most significant factor contributing to the file size of this SWF right now is the large number of embedded characters. If we browse through the assets being used in the SWF, we can come up with a list of the following fonts being used:

1. Helvetica Neue LT Std 95 Black
2. Helvetica Neue LT Std 67 Medium Condensed Oblique
3. Helvetica Neue LT Std 77 Bold Condensed
4. Helvetica Neue LT Std 87 Heavy Condensed
5. Helvetica Neue LT Std 97 Black Condensed
6. Helvetica Neue LT Std 107 Extra Black Condensed
7. Helvetica Neue LT Std 73 Bold Extended

This may seem like a large number of fonts, but it’s not uncommon to receive compositions that use at least this many. This in itself, though, is not necessarily a problem. Where things get messy is when we look at how the fonts are embedded.

In the case of our original file, we’re embedding every character in every font we’re using. If you look at the screenshot above, that’s almost 100,00 characters per font, or nearly 700,000 characters total. Most of the characters we’re embedding are entirely unnecessary. How can we resolve this issue? There are three ways.

1. Embed a smaller subset of the font. I generally use the following.
   
2. Embed only the characters being used within each text field. This is a fine option for fields that won’t be changing. You can accomplish this by first clicking “Don’t Embed” to clear any groups you’ve already included, and then clicking “Auto Fill.”
   
3. Make your text fields static. Generally this works well, although sometimes static text renders in unpredictable ways. This is also roughly equivalent to option 2.
   

After going through the source file and correcting every dynamic text field (using option 2), our 1.6mb SWF is down to a sweet and slim 36kb.

2. Image Compression

Another way we can influence file size is by toying with the JPEG compression settings for our SWF. By default, Flash embeds bitmaps at 80% of their original quality. Most of the developers I know rarely if ever tweak this setting, and in most cases it’s not necessary to, but if you’re willing to toy around the the figures you can squeeze a few more kb out of your SWF quite easily.

You can modify image compression in two ways.

1. Modify the global compression settings for your SWF. You can find this control in the publish settings panel under the “Flash” tab.
   
2. Modify the compression settings for individual images. When it comes to fine tuning your application, this is a better way to go. You can access this menu by selecting a bitmap in the library panel, right clicking, and selecting “Properties.”
   

This method is far from flawless, and the results are often hard to predict. In the case of the SWF we’re working with above, I’ve created a demo showing what the platypus photo in the background looks like at various compression levels. Click and drag the slider to adjust the quality of the image (displayed in the field next to the slider).

You probably can’t even see a difference before getting down below 70. From there to 40 the changes are subtle, and they become more noticeable with each step from 30 down. Obviously you have to know where to draw the line when you’re sacrificing image quality for filesize, though in the example above I would be willing to go perhaps as low as 20 if the need were great enough.

In our original SWF, setting the JPEG quality to 20 brought our filesize down from 36kb (after modifying our fonts) to a tiny 24kb.

3. External Libraries

Depending on what you’re trying to accomplish in your banner, you may require external libraries for animation or data connectivity. It’s easy to forget that including these libraries can add to the overall file size of your published SWF.

In our sample SWF we’re using the TweenLite library to animate bubbles across the screen and to remove them when they’ve cleared the left edge. TweenLite is a wonderful library, and it’s already quite small, but you may not be aware that there is a smaller version of TweenLite available called TweenNano. TweenNano is packaged with TweenLite, and unless you intend to do something highly complex it has all the same basic functionality.

The code in our original file for animating bubbles looks like this.

//
TweenLite.to(bubble, Math.random()*10, { _x: -150, ease: Expo.easeOut, onComplete: killBubb, onCompleteParams: [bubble] });
//

To switch over to TweenNano, all we have to do is change the name of the static class we’re referring to, like so:

//
TweenNano.to(bubble, Math.random()*10, { _x: -150, ease: Expo.easeOut, onComplete: killBubb, onCompleteParams: [bubble] });
//

Switching the code in our application from TweenLite to TweenNano brought our file size down from 24kb to a miniscule 20kb.

4. Flash Player Version

The final fix I would recommend for our sample file requires an awareness of the environment you’re publishing to and the needs and capabilities of your project. While it may seem at first that it’s best to publish to the latest version of FlashPlayer, if your application isn’t taking advantage of newer features it may be in your best interests to hang back with an earlier version.

Our original application, after all the cuts we’ve already made, was clocking in at 20kb published for Flash Player 8. If we publish to Flash Player 7, we reduce the filesize even further down to an insane 16kb!

What do we lose for the bargain? In this case, the ability to specify anti-aliasing methods for our text fields. Because this animation is simple, and nothing dramatic happens with text, we can part with those capabilities quite comfortably.

Of course, there are trade offs here as well. You may think that it’s better to publish to Flash Player 9 than 10 if your project doesn’t require features like native 3D support, but perhaps you could achieve some performance benefit by replacing your Arrays with Vectors?

Which version of Flash Player you choose to publish to will depend on your unique needs, but it’s worthwhile to remember that the latest is not necessarily the greatest.

Conclusion

After applying the above techniques to our original swf with a filesize of 1.6mb, we were able to reduce it to only 16kb. That’s a 99% reduction, and it’s sure to make clients and advertising networks happy. The new, shrunken files, can be found by following this link.

Keep these tips in mind and let me know if you have any other tricks for putting the squeeze on bloated SWFs.

So, beta versions of Flash Player 10.1 are already available, and a formal release is on the way. Which three features am I most excited about?

1. Global Error Handling

I’m planning on doing an article soon on error handling in Flash, but by the time 10.1 launches I’ll have to write another to highlight this great new feature. I’m consistently shocked by the number of unhandled flash runtime errors I encounter while browsing the web. Hopefully the addition of this feature will make it easier to handle some of them.

2. Out of Memory Management

Currently, it isn’t very easy or convenient to manage memory usage in Flash. This feature, while not making it explicitly easier, will at least allow swf content to fail more gracefully without obliterating the user’s state.

3. HTTP Streaming

Could it be true? Will I actually be able to legitimately stream video without having to pay companies like Brightcove and Edgecast to host it, and without having to install a streaming media server? If this is everything I hope it is, it will empower developers working on a smaller scale (me, for example) to deliver improved video experiences without breaking the bank.

This list is, of course, just a small selection of what I’m excited about. A full detail of the features that are on the way can be found here.