JavaScript – ready or not.

JavaScript Performance

There have been some very promising improvements in JavaScript performance, but exactly how good is it? It turns out, that there is a pretty easy way to work this out – thanks to haxe.

Haxe allows the same code base to be compile to Flash, JavaScript, neko and cpp. The graphics is handled differently – Flash uses its plugin, JS uses canvas and neko is using the NME library, running opengl. To compare these, I’ve chosen the Physaxe library, which is optimized for all these platforms, and can give a feeling for an app that has a computational and graphics load.

Into this mix, I will add another interesting option: The V8 JS engine, running using the NME library in opengl mode. This cross-over mode is actually quite easy to implement because of 3 stars aligning: 1. The NME library has a external interface that uses opaque handles that map very naturally to the v8::Value *. 2. The haxe compiler makes it possible to program JS without losing your mind, and all the existing library code is valid for this target. and 3: The Google V8 JS engine has a clean API that makes it easy to embed (you would almost think they designed it that way – dispite the frugal documentation).

The benchmark I have chosen is the “Pentagonal Rain”, which is nice and stressful for the CPU. You can try for yourself – use the ’5′ key to switch to this demo.

• JavaScript Canvas
• Flash
• Win32 Binaries (Neko, V8VM, CPP-compiled) (extract and drag the “.n” file onto neko.exe, or drag the “.js” onto the v8vm.exe)

So as you can see, the V8VM option is actually quite viable as a scripting vm. Since there is a lot in common between neko, v8vm and cpp haxe targets and plugin architectures, it should be relatively straight forward to switch between them.

The JS demo can run on the iPhone. But just because you can do something, it doesn’t not mean you should – at about 2 FPS on the title screen, I can’t imagine how slow it would run in the Pentagonal Rain demo. And probably not great for your battery either

Haxe Preloader For Flash – Written in Haxe.

There has been some talk about creating flash preloaders for haxe. However, these methods step outside the haxe toolchain and add some additional complication.

I have come up with a reasonably simple method for creating a haxe preloader in haxe, and then linking to a (very almost) unmodified swf generated in haxe using a small neko program to produce a single file. The neko program uses code from the hxformat project, some of which is provided so you can easily recompile the tool.

Since each original haxe swf contains one frame, the resulting code contains 2 frames. The first frame contains the preloader which waits for the whole file to load and then locates the PreloaderBoot class by name. This class runs the appropriate initialisation code, creating and running the correct “main” class.

For classes that appear in both preloader and the main swf, flash takes the first one – the one form the preloader. This means that both classes will have the same “flash.Lib.current” and (almost) everything will just work.

One complication comes from the fact that the flash.Boot class is given a unique name for each of the swfs. This means flash.Boot class in the main swf is not automatically “new”ed and placed on the stage, and the standard haxe initialisation code is not run. To compensate, we manually set the trace function and call the Boot initialisation code explicitly.

This sounds a little dodgy to me, but it seems to work – I will have to do some more testing.

The “Main” class in the example zip contains a resource to pad it out. The preloaded swf can be seen on it’s own screen. You can refresh to see it loading.

The example code is in haxe-preloader-0.1.zip

All code & data there is public domain, except for the hxformat code, which has its own license. Use at your own risk.