FlexAmphetamine

Recompress your Flash 11 SWFs with LZMA

2011-12-05T23:13:00.001-08:00

Flash 11 can load SWFs that have LZMA compression; previously SWF contents were either uncompressed or zlib-compressed.

Since the mxmlc compiler doesn't yet support this compression, and since it was a PITA to compile Tinic Uro's zlib2lzma on anything but Windows (http://blog.kaourantin.net/?p=124), and since no one else seems to have done it... I wrote a Python script to do the conversion. Woot. It only requires that the input SWF be compiled with -swf-version=13 (or higher). It will fail if you feed it an LZMA-compressed SWF -- feel free to fork me on GitHub and fix that.

Usage: python swf2lzma.py in.swf out.swf

Grab the code from: http://github.com/jspiro/swf2lzma

build decay chronograph

2011-07-19T04:59:00.000-07:00

After hours of coding and reloading, I constantly forget whether I reloaded a browser tab under development, and otherwise question whether the SWF actually got rebuilt (and am often wrong on both counts).

Enter the BuildDecayChronograph, an object that shows you how long it's been since a given SWF was last built, and a quick visual indicator from green to red of how fresh it is (for me, 5 minutes). The only requirement is that the given SWF was compiled with mxmlc.

Usage:
addChild(new BuildDecayChronograph(5*60, 'engine'));

Download from GitHub.

This could not have been done without the brilliantly hacky org.igorcosta.hacks.SWF

Blog Text and Codes (Igor Costa ) / CC BY-NC-SA 3.0

unable to transcode this meaningless error message

2011-07-14T19:00:00.000-07:00

If you're compiling with mxmlc on Linux, and you get the 'unable to transcode' error message, and you're transcoding hundreds of files... and you've wasted two days on this (no, I'm not bitter):

>: ulimit -a

That may be really small. Like 1024 files. Try compiling again after:

>: ulimit -n 5000

Better? mxmlc swallows the Java IO error #fml >_<

Tailing Flash

2010-09-30T16:31:00.000-07:00

>: tail -f /Users/jspiro/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt

How did it never occurred to me to tail with Flash before? Shameful.

Though, really, I wish I could control who gets to write to that log, or identify who IS writing to it -- there's so much spam from other running SWFs.

Dragging's a Drag

2010-09-17T14:35:00.000-07:00

For reasons that are beyond my comprehension, Flex List components have a property to allow moving of list items, but not one for copying.

If you allow moving, then you SURELY must also want to allow a poor implementation of copying, whereby your object is deep copied rather than cloned via some interface, putting Objects into your dataProvider rather than whatever class you were using. Also, copying is enabled by holding the control key -- not obvious to me, at least.

package
{
import mx.events.DragEvent;
import mx.managers.DragManager;

import spark.components.List;

/** Disables copy-dragging on List */
public final class NonCopyableList extends List
{
 override protected function dragDropHandler(event:DragEvent):void {
  event.ctrlKey = false;
  event.action = DragManager.MOVE;
  super.dragDropHandler(event);
 }
 
 override protected function dragOverHandler(event:DragEvent):void {
  event.ctrlKey = false;
  super.dragOverHandler(event);
 }
}
}

You're welcome.

Best Practices when Listening

2010-07-27T01:52:00.000-07:00

* Try to always use a weak listener, even though it's extra typing. The classes of bugs you are exposed to with strong listeners are mostly running out of memory, taxing the garbage collector, and killing performance as you take memory off the heap -- they creep up and are hard to detect. The classes of bugs with weak listeners are functionally worse -- but easy to detect -- stuff just doesn't work because the listeners got GCed (they are a little less performant too, due to tracking their weak-ness).

* When writing weak listeners: Make sure that objects you are listening on will not get prematurely garbage collected and are attached to something -- either the class, or some static Singleton.

* Make sure the object will get garbage collected eventually and write a comment about it.

* Assume that all weak listeners and objects will never get GC'd and will keep listening forever -- code for this. In other words, explicitly remove listeners when it is IMPERATIVE that you do not receive any more messages, do not rely on setting a parent to null to break the cycle.

* You DO NOT have to remove weak listeners if it doesn't matter if they continue to receive events until they GC -- e.g. a mouse move handler -- once you've removed the object from the display list, it doesn't matter that this handler MIGHT run. If you code your handlers to guard against runtime errors, then you never have to remove weak listeners. And if the listeners are still receiving after a long while... then you have a memory leak and the object you are listening on is not getting GC'd (see this post).

* If you are going to skip removing a listener, DOCUMENT IT at the line where you add the listener. If you won't document it, then don't do it.

* This is tricky stuff, so treat listeners with respect like you would NEW and DELETE in C++. Work them out in your head -- document the hell out of them. They are expensive and cause almost all memory and (many) performance leaks.

Random() Performance Tips

2010-07-27T01:35:00.000-07:00

* Perceived performance is more important than actual performance, and is cheaper to implement. Learn about how to fake speed in progress bars, and never, ever, ever, ever let Flash lock up while doing processing -- break work across frames and do it asynchronously -- keep the UI responsive even if it's modally locked.

* Initializing variables to null is unnecessary, costly, and distracting (when you're trying to read code -- null or zero unless otherwise specified).

* Eliminate "this." wherever possible -- this may be outdated, but in the past it produced better bytecode.

* Don't use coding conveniences like lots and lots of extra variables, WITH blocks, extra "this" statements. They all add space and time in AS3 even though most other languages would compile down equivalent statements to the same thing.

* Long package and class names get stored in the SWF -- interned strings in the constant pool are a large percentage of SWF size.

* Keep lazy initialization of datastructures to a minimum (e.g. if (!foo) foo = new Foo() versus private var foo:Foo = new Foo()) -- class init and static init code is smaller and only runs once. The only advantages to lazy init are for data structures that are expensive to keep around if not being used, and/or you will null them periodically.

* Function arguments and local variables are cheapest to use because AS3 doesn't have to search up the scope chain when you access them. Global statics are awesome -- though caching their values locally is best if you're going to reference them a lot. Deep lookups like foo.bar.baz.getterFunction() are expensive if you're going to do a lot of work in baz -- try caching foo.bar.baz first.

* Anonymous functions: Don't get me started ;) See this post.

* If you use Flex, grep -r validateNow -- and eliminate them unless absolutely necessary. And if you don't remove it, leave a paragraph on why it must be there.

* Getter functions cost more than versus get() functions; and they often have hidden side effects. Don't write a getter unless that's all it does, and in constant time.

* Mark ever variable as const unless you need it to be variable. One day there may be a performance benefit, like finals in Java. But until then, bask in one fewer category of bugs.

* If you're embedding gobs of XML (damned if I know why you'd need to do this): Pasting the XML into a class as a static XML object offers the best performance and compression. The compile-time processing and optimization is significant versus runtime parsing, type checking, and decompression in a ByteArray (if you compressed it on the wire)

JITing in the Flash VM

2010-07-27T01:14:00.000-07:00

Three things that came to mind recently:

* Constructors should be as short and fast as possible -- don't do any computation in them. The never JITs the constructor function, it's always fully interpreted. (There are performance tests to show this, though I know it for fact.) If you must do some work in the constructor, or the constructor will get called often (e.g. not a Singleton) -- write a private function to do the work and call it from the constructor.

* If you are using an Array and indexing it numerically (i.e. not an associative array -- one that uses string indexes), you can improve access speed to the array by hinting as follows:
array[int(idx*2+1)]
Even if idx is already an int, the type coercion sends a hint to the JIT.

* Finally, not so important, but in tight loops or ones with many iterations: Best practice is to cache the length of an array rather than inlining it: for (var i:int=0; i
It's been suggested to me that iterating over arrays backwards is faster -- though I suspect that's JIT/platform-dependent. It's confusing as hell, so I'd only suggest doing that if you're already doing something whacked out like dynamic programming =D

Printing in AS3

2010-04-08T20:38:00.001-07:00

Don't.

---
Okay, so I'm trying to be snarky. But since this blog occasionally attempts to be useful:

Printing in Flash has always been inconsistent, poorly implemented, and plain broken. As of Flash 10.1, it got some big updates to the point where it's actually useful.

You still cannot print vectors with transparency -- in which case you're forced to bitmap them first. You still cannot print bitmaps without them looking like shit. You cannot render decent quality bitmaps without using more memory than god.

But printing now works consistently (even if terribly) across platforms; vector printing really works now; and you can spool pages across frames (meaning a potentially unlimited number of pages, no longer timing out, and being able to show an animation and update progress while it chugs along). I can post code some day -- if there's demand.

Horizontal Mouse Wheel / Swipe Gesture Support in Flash

2010-03-30T21:03:00.000-07:00

It's possible to detect horizontal scrolling actions from the mouse or MacBook touch pads with a little JavaScript magic. Caveat: This only works on FireFox 3.1+ and Webkit-based browsers (Chrom{e,ium} and Safari). Microsoft still has not extended their events to send horizontal scroll messages*.

To do this, we're going to inject JS dynamically at runtime. I'm only giving you code snippets, you'll have to tie the logic together yourself.

First, you'll want to make sure you have a working ExternalInterface and add a callback to handle scroll events coming from JS:

if (ExternalInterface.available && ExternalInterface.objectID != null)
{
    try {
        ExternalInterface.call('eval', 'true;');
        ExternalInterface.addCallback("scrollEvent", onScrollEvent);
    } catch (e:Error){
        // nope!
    }
}

Here's your handler:

function onScrollEvent(xDelta:Number, yDelta:Number):void
{
    // scroll something in a fancy manner by xDelta and yDelta
    // note: Webkit may give you TWO non-zero values as it allows
    // simultaneous scrolling
}

Now we need to drop the JS into a String const:

const SCROLL_SCRIPT:String = (<![CDATA[
    function setupScrolling(objectID)
    {
        var flashObject = document.getElementsByName(objectID)[0];
        var eventListenerObject = flashObject;
        var isWebkit = false;

        if (navigator && navigator.vendor)
        {
            isWebkit = navigator.vendor.match("Apple") || navigator.vendor.match("Google");
        }
        
        // some events will need to point to the containing object tag
        if (isWebkit && flashObject.parentNode.tagName.toLowerCase() == "object")
        {
            eventListenerObject = flashObject.parentNode;
        }
        
        var scrollHandler = function(event)
        {
            var xDelta = 0;
            var yDelta = 0;
            
            // IE special case
            if (!event)
                event = window.event;
            
            // IE/Webkit/Opera
            if (event.wheelDelta)
            {
                // horizontal scrolling is supported in Webkit
                if (event.wheelDeltaX)
                {
                    // Webkit can scroll two directions simultaneously
                    xDelta = event.wheelDeltaX;
                    yDelta = event.wheelDeltaY;
                }
                else
                {
                    // fallback to standard scrolling interface
                    yDelta = event.wheelDelta;
                }
    
                // you'll have to play with these,
                // browsers on Windows and OS X handle them differently
                xDelta /= 120;
                yDelta /= 120;
    
                // Opera special case
                if (window.opera)
                {
                    yDelta = -yDelta;
                    // Opera doesn't support hscroll; vscroll is also buggy
                }
            }
            // Firefox (Mozilla)
            else if (event.detail)
            {
                yDelta = -event.detail/1.5;
                // hscroll supported in FF3.1+
                if (event.axis)
                {
                    if (event.axis == event.HORIZONTAL_AXIS)
                    {
                        // FF can only scroll one dirction at a time
                        xDelta = yDelta;
                        yDelta = 0;
                    }
                }
            }
    
            try
            {
                flashObject.scrollEvent(xDelta, yDelta);
            }
            catch(e) {};

            if (event.preventDefault)
                event.preventDefault();
            event.returnValue = false;            
        }
        
        if (window.addEventListener)
        {
            // not IE
            eventListenerObject.addEventListener('mouseover', function(e)
            {
                if (isWebkit)
                {
                    window.onmousewheel = scrollHandler;
                }
                else
                {
                    window.addEventListener("DOMMouseScroll", scrollHandler, false);
                }
            }, false);
        }
        else
        {
            // IE
            flashObject.onmouseover = function(e)
            {
                document.onmousewheel = scrollHandler;
            };
        }
    }]]>).toString();

Finally, execute it in the browser:

ExternalInterface.call("eval", SCROLL_SCRIPT);
ExternalInterface.call("eval", 'setupScrolling( "' + ExternalInterface.objectID + '" );');

Try it out (click the logo to look at my other documents at Scribd!) -- zoom in as far as you can go:

---
* Poor man's support for IE: Use a modifier key to enable horizontal scrolling. For instance, vertical scrolling works as usual -- and if you want hscroll, hold down CTRL while vscrolling.

Finding Unused Classes with MXMLC

2010-02-24T13:30:00.000-08:00

I came up with a quick and dirty method for finding unused AS3 clsses if you compile with MXMLC. The trick is to use a hidden compiler flag that I added while at Adobe: --keep-generated-signatures (and -incremental must be on too). This outputs a generated-signatures directory in your source tree filled with .sig files (named using the package structure, delimited by underscores: mx_core_Foo.sig). These are all the AS files that were compiled and/or synthesized in-memory (e.g. from [Embed] metadata) by MXMLC.

So, now you have a list of AS files that were compiled. Now we need a list of files that we have. cd to your source directory (if you have more than one, you're on your own):

$ cd src/
$ diff <(find . -name "*.as"|sed 's@\./@@'|sort) <(find generated-signatures -name "*.sig"|sed 's@generated-signatures/@@'|sed 's@_@/@g'|sed 's@\.sig@.as@'|sort)|grep "<"|sed 's@< @@'

This should give you a list of files that do not have signatures in the compiler, and should be safe to remove.

For the curious: .sig files are public class signatures -- they are a canonically ordered list of every function, field, import, metadata, etc., that could potentially have a dependency, in either direction, on another class being compiled. One way I used this was for an optimization to determine if a class' dependencies need to be recompiled or not -- if the signature didn't change, they don't. Every AS class gets a signature generated -- on the extremely rare case where a signature can't be generated (due to unforseen syntax or something), a warning is printed with mini-stacktrace to the console -- if you don't see that, you can be sure it's complete.

Closure on Closures, Terrible Typing, For-Each Failures

2009-12-13T23:25:00.000-08:00

Here's an old reply I wrote to another blog's wonderings on performance problems in Flash functions, numeric types, and array access. I'm not in the mood to review, rewrite, nor make corrections (e.g. I'm sure I used "function closure" where I meant "activation object" and vice-versa, but not important), but here's the text of my replies (not entirely self-contained, but I recommend reading the original post either way):

From http://robert.zubek.net/blog/2008/01/12/actionscript-3-bytecode-performance/#comment-258

Anonymous functions/closures have tricky semantics in AS3, which is why you saw such painful numbers.

AS3 is not block-scoped, so all variable definitions are hoisted to the top-level of their scope — in this case, the function body of the surrounding function, not the anonymous function. This is why you cannot have two for loops with the same ‘var i:Number’ definition — you would get a ‘Duplicate name i’ error.

So, when you introduce an anonymous function, the cost of *every* variable (within the outer function down to the deepest variable definition) is increased considerably. You have to do a more expensive lookup. This is why the Flex SDK doesn’t use them, ever :)

Sometimes, you *need* a closure for an event listener… My solution is to create a simple factory function that takes the values you want to close over, and returns a Function object. This doesn’t get around the cost of creating a closure, and it adds the cost of the factory function call, but it isolates the lookup costs to the factory function.

In small functions, it may be more expensive to use this technique, but I never tested it.

—

As for for-each loops: The special form returns values from an array in unspecified order because the backing object is a hashtable (it sometimes begins life as a dense array, but often becomes a hashtable). Assuming that your for(;;) test was iterating over indexes from 0..len-1, each iteration does a hash lookup. We’d like lookup to be O(1) amortized, but there is considerable hidden overhead in doing the lookup.

The hash function is a quadratic probe, and we have a high load factor (~80%), so a large array has a high probability of collision. To calculate the address, integers indexes must be cast to Number (not terrible, but this is why the Flex SDK uses Number instead of Integer). If you index on a string or the cast fails, we stringify the index, intern it, and use that (!).

You *might* be able to tell if you have a dense array if the ‘for each’ loop returns items in ascending order, but that’s just a guess. You could try it with a 10 element array versus a 1000 element array, perhaps.

Player 10 should improve some of the casting costs and differences in performance between numerical types.

—

Another gotcha. Though no professional uses them, ‘with’ blocks introduce the same overhead that anonymous functions do, without any of usefulness. [Ed: It was pointed out to me that it's super-useful in graphics code -- true! though given the number of instructions you're likely to give for any non-trivial graphic, you're best off making a variable named g and being explicit about it.] You push the with object onto the scope chain, and then have to search the scope chain for every call within that block.

Too bad we didn’t implement them the way VB did, where you could tell which statements used the with object because they all started with a “.” (of course, there would be limitations).

Many equivalent expressions in AS3 are not equivalent in byte size or performance. Many of the convenience mechanisms, like with, are useless because their performance is so poor. I always meant to explore this and actually write posts in my blog, flexamphetamine.

By the way: Have you tested different kinds of variable accesses? I forget what my results were (two years ago…), but this might have been the order of expense (from least): argument variables (strange, huh?), local variables, class variables. I don’t think I tested statics.

Alphas Go to Eleven

2009-03-26T20:29:00.000-07:00

In case you've always wondered why setting alpha to 0.9 doesn't return 0.9 when you read it back...

Internally, alpha is stored as an integer between 0 and 255, and auto-rounded/converted from the input of [0, 1.0]. This is braindumb design, but a fact of life.

So if you add 0.1 ten times to an alpha of 0, you get a number less than 1.0, and need to go to eleven (going to eleven is usually a good thing, but in this case it isn't).

If you are incrementing the alpha by 0.01, the actual alpha will be off more than 20% by the 100th iteration (!).

So the only way to keep alphas honest is to store the last value you tried to set alpha to, and use that as the input in your code.

Moral: Don't use the existing value of alpha (ever), always set it and manipulate it from a model.

Monkeypatching the cached Flex framework RSL

2009-02-08T15:18:00.000-08:00

I believe I discovered a *consistent* method to monkeypatch the Flex framework with RSLs. I assume you understand what a preloader is, and how to monkeypatch without RSLs -- there is plenty of documentation on both.

Like the first time you type sudo:

We trust you have received the usual lecture from the local former Flex SDK dev. It usually boils down to these three things:
    #1) Respect the privacy of other classes.
    #2) Think before you patch.
    #3) With great power comes great responsibility.

Create an empty preloader class (or add to an existing one) which contains the following, substituting for whatever you're patching.

    import mx.managers.FocusManager; FocusManager;

And that'll do it. The class will get preloaded, before the cached framework gets loaded. Simple and obvious now, eh?

---
Note: If using RSLs, you may see significant code bloat. Classes get loaded in order of dependency -- if the dependency of UIComponent isn't present when it tries to load, it fails.

So if you are patching high up in the dependency tree, like UIComponent, all the required classes will get compiled into the main SWF, as they are loaded before the RSLs.

Notably, this is unlike how Java's class loader works.

Heisenberg on Garbage Collection

2009-01-08T21:50:00.000-08:00

Detecting if a reference gets garbage collected is tricky. In general, you cannot do this because of the Heisenberg Uncertainty Principle -- if you hold a reference, then it cannot get GCd; if you don't hold it, then you cannot check if it got GCd. Until now :)

Example (try uncommenting the line which nulls our important reference):


// the object we're curious about
var impReference:Object = new Object();
public function init():void
{
// this code monitors an object for GC, giving it a name.
monitorGC("impReference", impReference);
//impReference = null; // try uncommenting me

// GC rarely occurs until after code runs, after a frame or so
callLater(function():void
{
// call twice USUALLY makes a GC occur, as does opening
// a LocalConnection to the same name twice in a row
System.gc();
System.gc();
// look at the error console
if (checkIfGCd("impReference"))
trace(name + " got GCd")
});
}

// support code
static public function monitorGC(name:String, reference:*):void
{
// this is how we get around Heisenberg, a strong Dictionary holding
// weak dictionaries, each holding a single reference, or no references
(gcReferences[name] = new Dictionary(true))[reference] = true;
}

static public function checkIfGCd(name:String):Boolean
{
var gotGCd:Boolean = true;
for (var foo:* in gcReferences[name])
gotGCd = false;
return gotGCd;
}

static private const gcReferences:Dictionary = new Dictionary();