When talking about accelerated 2D in Flash, everybody is always asking for performance comparisons. So I threw together a little speed test for ND2D. Mainly to give you some numbers, but also to test the different implementations of ND2D‘s objects. After selecting one of the four different options, the test will keep adding sprites until the framerate drops below 60hz. While adding sprites, it’s likely, that the framerate drops below 60hz for a short while, because adding and creating objects is expensive too. But what counts is the end result.
This test allows you to compare four different types of objects / rendering:
- Sprite2D with a shared texture. Every sprite is drawn in a seperate drawCall, but there’s only one texture in memory
- Sprite2D with individual textures. A drawCall for every sprite is used as well and there are as much textures in memory, as there are sprites
- Sprite2DCloud. All sprites have a shared texture and are drawn in a single drawCall. All movement is calculated on the CPU and the vertexbuffer is uploaded to the GPU every frame
- Sprite2DBatch. Shared texture as well, but most of the work is done by the GPU with batch processing.
The results on my machine in Chrome at fullscreen resolution (1680 x 1050) and the Flash Player 11 Release (Please, don’t try it in the debug player, it’s way slower) are:
- Sprite2D shared Texture: 2157
- Sprite2D individual Textures: 1881
- Sprite2DCloud: 14579
- Sprite2DBatch: 6180
There are still a lot of things, that can be optimized. For example, I’m not saving and comparing state changes in the context (texture bind / unbind checks, etc.). At least the first test could be optimized a lot with this technique I think. Even though there is still space for optimization, I’d say that ND2D is fast enough to build some stunning games! Who needs 15 thousand moving sprites in a game? That should be more than enough ;)