[![](/wp-content/uploads/2011/07/header.png "header")](/wp-content/uploads/2011/07/header.png)

Ive spent a little more time this weekend looking at some more  HTML5 with HaXe. Following on from [my previous experiments with WebGL](/posts/chrome-crawler-haxe-three-js-webgl-and-2d-sprites/) I decided to give HTML5's Canvas a a look as it was supposed to be designed specifically for the purpose of doing 2D.



I had heard from the HaXe mailing list that the [Jeash project](https://haxe.org/com/libs/jeash) was a common way of interacting with the canvas in HaXe. Jeash is a remapping of the Flash API into JS so in effect I should beable to take any of my usual flash code, Sprite's,  BitmapData's, etc and it should run on the canvas no problems. Nice!

So I coded up a quick blitting example to see what sort of performance I would get:

[/projects/HTML5SpeedTests/HaXeJeash/bin/](/projects/HTML5SpeedTests/HaXeJeash/bin/)

The results were okay (I get about 11FPS with 5,000 crawlers) however I was interested to know what sort of cost HaXe adds. So I decided to code up a second example, this time using pure JS:

[/projects/HTML5SpeedTests/JSCanvas/](/projects/HTML5SpeedTests/JSCanvas/)

The results this time were better (14FPS with 5,000 crawlers) so I now wondered what happens if I do without Jeash and just code up the example using pure HaXe. I was expecting to see the same sort of performance hit as Jeash:

[/projects/HTML5SpeedTests/HaXeCanvas/bin/](/projects/HTML5SpeedTests/HaXeCanvas/bin/)

Surprisingly it actually runs faster (17FPS with 5,000 crawlers) ! This is quite a surprise and totally contradicts my notion that going from HaXe -> JS would incur a cost. I was expecting some cost, but a performance increase?! I can only speculate that behind the scenes the JS engine in the browser is able to JIT compile the HaXe JS much better than the hand-crafted JS and hence more speed.

If you are interested in the source then I have uploaded it here: [/projects/HTML5SpeedTests/HTML5SpeedTests_1.zip](/projects/HTML5SpeedTests/HTML5SpeedTests_1.zip)

P.S. All the test were run on Windows 7 x64 in Chrome 14 (dev)

[![](/wp-content/uploads/2011/02/commandlin01.jpg "commandlin01")](/wp-content/uploads/2011/02/commandlin01.jpg)

Binding in flex has been playing on my mind for a little while now, so I have decided to finally sit down and try to resolve the issue.



The worry has been that on large projects that make heave use of the flex automatic binding, compile times could be dramatically increased. This is because behind the scenes the flex compiler must convert those syntax sugar ([Bindable] and {}) into actual AS3 code. The exact way this is done I wont go into, but I recommend you google it, its a fascinating topic.

I really like the ease of use of automatic binding but at the same time I was worried about how much slower compile times are because of them. So I decided I would try to run some tests and see.

To compare the compile time performance of binding I ran three tests. The first, a control to define how long compilation takes with an empty Flex Application. The second tests how long non-binding takes and is comprised of a single group with 4000 labels that are assigned values. The third test is for binding and is 4000 labels that are bound to 4000 [Bindable] public variables.

For testing metrics I used the -benchmark=true compile flag along with -incremental=false to stop any sort of compile-caching. The full command line compile looks like:

> "E:Program FilesAdobeAdobe Flash Builder 4sdksflex_sdk_4.5.0binmxmlc.exe" -load-config+=MainConfig.xml -debug=true -incremental=false -static-link-runtime-shared-libraries=true +configname=air -benchmark=true
> I ran each test three times and took the average of each. I then ran the entire thing again but with -debug=false to see if that would make any difference.

I recorded all the results in this google doc: [https://spreadsheets.google.com/ccc?key=0AoHeesrTENc9dEFqamdCc2ZldHcyZkJmQkZsaDBOT0E&amp;hl=en&amp;authkey=CLP8r-MF](https://spreadsheets.google.com/ccc?key=0AoHeesrTENc9dEFqamdCc2ZldHcyZkJmQkZsaDBOT0E&hl=en&authkey=CLP8r-MF)

The general gist is that it seems binding adds about 20% onto compile times both- debug=true and -debug=false. This isnt as bad as I was fearing but still a 20% increase on a 30 second compile time can be annoying.

Im not sure if the tests I did were fair so I would love to hear feedback from others.

I have bundled the project up incase anyone wanted to test it themselves: [/wp-content/uploads/2011/02/CompileTestGen.zip](/wp-content/uploads/2011/02/CompileTestGen.zip)

[![](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-31-14.04.jpg "ScreenHunter_01 Aug. 31 14.04")](/wp-content/uploads/2010/08/ScreenHunter_01-Aug.-31-14.04.jpg)

So I have [written about Mr Joa 'The Flash God' Ebert before](/posts/funk-ioc-a-new-dependency-injection-framework/). He is well known throughout the Flash community for his incredible coding skills, particularly his work on low-level SWF optimisation.



His latest project is called JITB and its nothing short of stunning as this video taken [from his blog](https://blog.joa-ebert.com/2010/08/31/so-i-recorded-a-new-video/) shows:

<iframe width="100%" height="400" src="https://www.youtube.com/embed/atzHF7YGp6Y" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Basically he has gone and written a Flash Player in Java. What this means is that you get all those awesome speed benefits and optimisations that the Java team has worked hard for years and years to implement but you can write it all in a language already familiar and sexy, AS3! The result? You get about a 30x speedup! (disclaimer: a micro-benchmark taken from Joa's blog)

This is all great news and very exciting. I cant wait to see a custom browser plugin using this flash player, or even having Pixel Bender shaders running on the hardware _me drools in anticipation_.