ASNext was supposed to solve once and for all AS3 VM performance problems.
ASNext is now canceled, but the problem remains.
Why and how slow is AS3?
We know AS3’s VM and JIT aren’t very efficient in general, partly because the language is fairly rich and dynamic; and even if the VM was awesome, all maths are computed with double numeric types which are known to be massively slower than floats.
However compared to other scripting languages, we shouldn’t complain that it’s slow – AS3 AOT-ed on iOS is definitely much faster than interpreted LUA for instance, so why is that such a problem in AIR and not in Corona/MOAI/Gideros?
The problem is Stage3D
And more precisely, the problem is Stage3D being a very low-level API.
A low-level API offers a lot of freedom, and you have to give credit to Adobe for creating an efficient abstraction of DirectX, OpenGL and OpenGL ES.
However, this freedom imposes a much bigger pressure on the scripting side – and that’s where AS3 falls short, mostly because it requires a lot of numeric computations.
Let’s look at Haxe NME – the Haxe language is close to AS3, cross-compiled to C++, using doubles for maths like AS3, so the resulting executable shouldn’t be meaningfully faster than AS3 AOT on iOS.
However 2D benchmarks tell a different story: CPU usage is a lot lower and framerate (generally) a lot higher for identical scenes.
The difference? It’s the API!
The closest API to Stage3D in NME is drawTriangles. As with Stage3D you must provide the complete geometry; it’s GPU accelerated, flexible, but it’s far from being the fastest option.
NME’s secret is that instead of having to do all the computations in Haxe, you can use:
- a Tilesheet object holding rectangles definitions (ie. UVs,size,pivot) for a Spritesheet,
- and the drawTiles method wich only requires a list of (x,y,rect_id,scale,rotation) or (x,y,rect_id,2x2_matrix).
- These datas are passed to the runtime which does all the computations using optimized C++ maths.
The result: no double bottleneck.
Conclusion: we want drawTiles in AS3
In addition to IndexBuffer3D + VertexBuffer3D, I’m calling Adobe for the addition of a Tilesheet + TileBuffer3D which would expose a similar API to generate geometry more efficiently.
And although the quads are generated in 2D, it still goes through vertex shaders so there’s no reason it should be limited to flat 2D rendering, but anything that needs to animate quads or triangles (“mmmh, particles!”).
Come on Adobe, how hard could it be to implement?
PS: do you see other easy API additions that could help?