LAFlash

I’ve had this blog post on my mind for a good long while now, brewing, as I collected more and more ammunition for the day that I finally got annoyed enough to put this down on paper, or blog, so to speak. Over the last 6+ months the debate between developers on the web front have been adamantly defending their technology choices and presenting the best cases they could think of to prove to the other side why their technology choice is better.

Personally, I have been just as guilty as the next dev of adding fuel to the fire. Instead, what we should be doing as Flash developers, and as JavaScript/[insert your preferred language] developers in general, is making sure that the software that we put out to the public is the best software we could possibly make. Sometimes this means being up to date with all the latest and greatest frameworks for your language. Other times it means learning a spiffy new debugging tool, or a completely new IDE that makes you write code 10x faster than you did with your last IDE. Sometimes, it simply means 1 simple thing, and pardon my french here, but, KILL YOUR FUCKING TRACES!

Start Rant:
There are several reasons to do this, but in a time where everyone in the web development community is looking at Flash developers and looking for any reason to say, “See, I told you Flash sucks.”, we as Flash developers need to make sure that we at least take the simplest of steps to make our Flash SWFs run as smooth as possible. Even on the fastest of computers a single trace statement can bring your application, and the user’s computer, to a grinding halt. Its as if a lot of developers believe that because it is a simple trace() statement that it shouldn’t or doesn’t hurt performance, when in actuality it does. Even on SWF files that I have compiled with “Omit traces” on, if you run “tail -f /path/to/ur/flashlog.txt” you will still see all those traces that a developer would think are no longer being executed with “Omit Traces” on. With the entire web development industry now looking at how Flash performs we must be more diligent about doing simple things like this. This type of simple oversight is EVERYWHERE. Lets see what I found while doing a quick search online…

As soon as I hit “tail -f …” I was immediately bombed with traces. These traces below come from Google’s video adwords, I guess its important for the user’s computer to know that the “Font still too big even at minFontSize”. I can rest easy at night now.

Next is CNN.com, the video player here is nuts.  I think they trace enough information from their video player to reverse engineer it from traces.  As soon as I loaded this page my Terminal was off the charts, this screenshot does not give justice to their trace mastery.  You are also greeted by several welcome messages, also known as Run Time Errors.

ESPN.com is just as bad, this is what shows just by loading their home page.

These are just three quick examples, I can sit here all day and call people out.  The point is, it is so simple to make sure your applications have all traces commented out, it improves performance in our Flash SWFs, and it gives people one less thing to bitch about Flash.

I have used express install on many projects without having many issues, but today I ran into an issue that was either making the express install window not display at all, or when it did display, it would not allow the user to click on the OK or Cancel buttons.

The issue seems to be isolated to Flash Player 10.0.45.2, on all browsers, while trying to update to 10.1.53. I narrowed down the issue to setting the wmode parameter to either “direct” or “gpu” for hardware acceleration while using express install.

I’ve logged this in the Adobe JIRA bug base. But I wanted to post my workaround here if anyone is experiencing this issue and is looking for a resolution. To get around the bug I simply wrapped the parameter in an if clause. Hope this is helpful to someone!

<script type="text/javascript">
        <!-- For version detection, set to min. required Flash Player version, or 0 (or 0.0.0), for no version detection. -->
        var swfVersionStr = "10.1.53";
        <!-- To use express install, set to playerProductInstall.swf, otherwise the empty string. -->
        var xiSwfUrlStr = "playerProductInstall.swf";
        var flashvars = {...};
        var params = {};
        params.quality = "high";
        params.bgcolor = "#000000";
        params.allowscriptaccess = "sameDomain";
        params.allowfullscreen = "true";
        // Only set wmode if the right Flash Player is present.
        if (swfobject.hasFlashPlayerVersion(swfVersionStr))
        {
                params.wmode = "direct";
        }
        var attributes = {};
        attributes.id = "MySwf";
        attributes.name = "MySwf";
        attributes.align = "middle";
        swfobject.embedSWF(
            "MyFlashApp.swf", "flashContent",
            "900", "650",
            swfVersionStr, xiSwfUrlStr,
            flashvars, params, attributes);
        <!-- JavaScript enabled so display the flashContent div in case it is not replaced with a swf object. -->
        swfobject.createCSS("#flashContent", "display:block;text-align:left;");
    </script>

After working in Flex for so long I’ve grown used to some of the great utilities that Flex provides. One of the classes I think is very useful during debugging is mx.utils.ObjectUtil. Using “ObjectUtil.toString()” you can very easily trace out objects that you want to inspect the contents of. So I took the mx.utils.ObjectUtil class and modified it to remove the dependencies on Flex framework classes so that it works in AS3 projects only. Not only in AS3 projects in Flex Builder and Flash Builder but in the Flash IDE as well.

Read the rest of this entry →