Tag Archives: actionscript

From Banners to Apps

Last week I gave a presentation to the Midlands Flash Platform User Group. This was the result of some thoughts & conversations which started to fizzle around my brain during last year’s Flash on the Beach conference. The talk “From Banners to Apps” was a brief (ish) distillation of my 15 years’ in the Internet industry – what I have done and what I have learned. I was quite pleased with how it went (although it was far from perfect – if I were to do it again then I would try to encourage a bit more two-way communication with the audience).

Here is a PDF copy of my presentation, complete with vaguely-cryptic presenter notes.

Am I Completely Insane Or What

Another ActionScript-related memory-usage post. I’ve been doing some experiments with flash.display.Loader (a class which has always seemed out to get me). Today I discovered something which is just so weird it makes me doubt my own sanity. I’d be grateful if any Flash/Tamarin experts out there could help me verify my sanity/insanity.

Here is the test script I’ve been running:

public static const NUM_LOADERS:int = 500;

public function TestMultipleLoaders()
{
init();
}

private function init():void
{
for (var i:int=0; i < NUM_LOADERS; i++)
{
createAndDestroyLoader();
}
}

private function createAndDestroyLoader():void
{
var loader:Loader = new Loader();
loader = null;
}
}

Compile this in Flash Builder and test it under the Profiler. Change the filter to include objects in the flash.* package. Observe how many Loader instances are in memory. Hit the garbage collector. Observe again.

If your system is running anything like mine, you will see 500. Which, in itself, is crazy. loader is just a local variable which, anyway, is set to null. But bear with me, this is going to get crazier…

Now try playing with the value of NUM_LOADERS. Again all things being equal, you will see this crazy behaviours (NUM_LOADERS Loaders persisting in memory) for any number between 1 and about 600. Somewhere around that figure, perhaps a little higher (it doesn’t seem to be predictable) you will see the number of Loaders persisting drop to either 1 or 0.

Now what the hell is going on here? My guess is that the Loader class is somewhat resource-intensive to create, and so Adobe are maintaining a pool of them somewhere, although the strategy for doing it seems a bit random.

Please can somebody, anybody, enlighten me?

Embed types in ActionScript and memory usage

I’ve spent the last few days doing lots of fascinating ActionScript memory-tests – and hopefully I’ll post some of the results here if I get time – but while I have a quick moment I thought I’d share this finding which (while obvious now I think about it) caught me out.

The Embed meta-tag allows you to embed and access external files directly within your SWF, e.g.

[Embed(source = 'myImage.png')]
public static const MyImage:Class;

Flash seems to automagically detect the MIME-type of your embedded content (in this case, image/png), so that when you call new MyImage() the resulting object can be cast to a Bitmap.

You can, however, explicitly set a MIME-type for the embedded asset. If you’re crazy enough, you can do this:

[Embed(source = 'myImage.png',mimeType='application/octet-stream')]
public static const MyImage:Class;

This time calling new MyImage() will return an object of type ByteArray; in order to convert it into a bitmap, you will need to load the ByteArray into a Loader object.

Now, what caught me by surprise is the way in which the Flash compiler embeds the file myImage.png; I had foolishly assumed that the binary file would be embedded as-is, and then handled appropriately at run-time, but the compiler is a little smarter than that, and tries to handle the binary data according to its MIME-type. This is probably best demonstrated by example. In my test case, I embedded a large uncompressed PNG – the file was 1280×720 and came out at approx. 2.7MB.

With the first style of Embed (the “regular”), my compiled SWF was approx. 1.7MB or so in size, and when I ran it it decompressed to a similar size.

With the first style of Embed (the “byteArray”), my compiled SWF was a much smaller 800kB in size, but when I ran it it decompressed all the way back to 2.7MB.

I’m still trying to get my head around the implications of this (with a lot of help from Tish!) – it seems counter intuitive to me that the decompressed file sizes are so different, when presumably the “regular” version will have to be decompressed to a full 1280x720x4 (ARGB) bitmap data object. Any thoughts?

2008: Work

Like I said, I’ve been meaning to post a summary of my last 18 months. Perhaps easier if I split it into two: work, and personal. So, work: I started freelancing in the middle of 2007, and I’ve done a whole bunch of interesting jobs since then (see my CV for full details).
Continue reading 2008: Work

Clean Code by Robert C Martin et al

Clean Code: A Handbook of Agile Software Craftsmanship, by “uncle” Bob Martin & his associates, is a great book, and one which any developer will learn a great deal from. In most respects, it is a five-star book, but… the title is misleading. By rights it should be called “Clean Java Code”.
Continue reading Clean Code by Robert C Martin et al

Mouse-wobbling blobby things

I’ve been spending the last few days on some rather interesting ActionScript challenges. I’ve been building a sort of a lava lamp gloopy movement machine. I’ve been up to my neck in physics and trigonometry, so today when I had to change the way that the mouse moves objects around in the “gloop”, I got too carried away with triangles and tangents before coming home to think, and realising how simple it ought to be. Here’s some fun code, paste it into any MovieClip in Flash: put it on the first frame and then on the last frame, add a simple gotoAndPlay(2) so that the initialisation doesn’t take place twice. Or turn it into a proper object: this is just my quick & dirty version:
Continue reading Mouse-wobbling blobby things