Header image

ND2D – Speed tests

October 23rd, 2011 | Posted by lars in Molehill / Stage3D | ND2D | Talk

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.


Hit ‘F’ for fullscreen

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 ;)

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

15 Responses

  • That’s impressive! I love the ND2D API, much better than Starling’s.

    Also, I was wondering however if there is a way for the sprites to not be smoothed if I want to scale them 2x or 3x, to get a pixel look?

  • Intel i5 2.27 GHz, 4GB RAM, ATI Mobility Radeon HD 5400
    Results for me in Chrome on Windows using FP11 Release:

    Sprite2D shared Texture: 603
    Sprite2D individual Textures: 177 (stabilized at a framerate of ~40)
    Sprite2DCloud: 43 (stabilized at a framerate of ~40)
    Sprite2DBatch: 476 (stabilized at a framerate of ~40)

    Something obviously not right here.

  • Tyler says:

    Interesting. When I go to full screen, I get much better performance, at least with the Sprite2DCloud test (I didn’t try the others in full screen). I get around 8500 with the window as normal and then around 14,500 in Full Screen. This is Chrome. I also noticed that mouse over events really slow it down when there are over 14000 sprites on there. :) Is disabling mouse events currently possible?

    In any case, this is cool. It’s especially impressive that size no longer makes much of a difference. Unlike with bliting, if you make these objects larger, performance doesn’t degrade much.

  • lars says:

    @Mat: Texturesmoothing options are on my list and will be added soon.

  • Shawn says:

    Windows 7 w/ Radeon 4850 GPU, Intel Quad Q6700 @ 2.6ghz

    Sprite2D shared Texture: 1160
    Sprite2D individual Textures: 1180
    Sprite2DCloud: 4998 (really constant fluctuation here, between 45 and 60, kinda weird)
    Sprite2DBatch: 2668

    The cloud test never really seemed to settle in, it would just fluctate back and forth between 60 and some lower number. The lower number would keep going down and down… I eventually stopped when it got down to 43, it didn’t show any signs of stabilizing…

    Also, very weird that the individual textures outperforms shared textures… wonder why that is.

  • lars says:

    Adding childs to a Sprite2DCloud is very expensive, that’s why it fluctuates. The framerate goes up again, when the sprite has been added and the buffer is reinitialized. This test takes a while, but in the end, the framerate will be stable and slightly below 60hz.

  • Why are you working so hard for free … Starling Framework is being backed by Adobe itself, sooner or later it will outgrow you … I don’t mean to de-motivate you … but you should move on, you are obviously talented … work with Adobe or something … cheers

  • Paul Schlichter says:

    Impressive! My results:

    Phenom II X6 1090 @ 3.2 GHz | 8 GB | ATI Radeon 4870 | Win7

    Sprite2D shared Texture: 2586
    Sprite2D individual Textures: 2381
    Sprite2DCloud: really slows down when adding Sprites above 6K, skipped it at 8K
    Sprite2DBatch: same here, skipped at 6K

  • Paul Schlichter says:

    Ah, btw, do you have access to a mobile prerelease? If yes, how is it doing performance-wise?

    Greets Paul

  • lars says:

    @Paul: Sorry I can’t tell. I signed a NDA not to tell anything about this topic :)

  • lars says:

    @Mustafa: You know, some people like to experiment with new technologies and push them to their limits. My motivation still is to learn more about API design, efficient GPU programming and shaders. My little side project ND2D is perfect for these goals and if someone likes to use what I do, it’s perfect. Besides of that, there will never be “the one framework” for all usecases, that’s a bit narrowminded. There are just too many specific requirements for different types of games. So choose, what fits your needs best. As you can see, there are already other 2D libraries out in the wild: M2D, Genome2D and more will come.

    So, have fun exploring…

  • Tyler says:

    As far as Starling goes, it’s also worthwhile to note that ND2D has already served to show areas where Starling can be improved. People have been asking for improvements in Starling (and it sounds like they’re coming) simply because they saw ND2D do them first. In short, ND2D is already helping Adobe. Thanks for your work here. This is helping a lot of people both directly and indirectly.

  • I get a similar inversion of results on my Mac Mini (Snow Leopard with nVidia GeForce 9400). Sprite2DCloud has a much much lower cap (~250) than Sprite2DBatch (~3K+)

    And API investigation and experimentation is a damn fine reason for creating open source projects. :-)

  • gene says:

    i’m troubled with the matter about quad batching. i batched 30 quads(120 vc) within one batch, and the quad textures is paint a humanbody that some parts of the pic are 0 alpha.
    Before calling draw() this batch, the quads vertex index has been sorted by z axis from far to near. OK, with context3d.setBlendFactors(SOURCE_ALPHA, ONE_MINUS_SOURCE_ALPHA) and context3d,setDepthTest(true, LESS_EQUAL), there shows the rigth depth and alpha blend effect.
    Then,after the batch drawed , here i wanna go on to draw a quad( or more) which is with a z-axis value among the z-axis values which R of just mentioned quads batch. i aim to draw a new quad locates among the quads last batched.
    The problem is showing, the alpha blend is wrong! :( it didnot approach to my aim. the batched quads blend the background color but not the zero alpha wanted, with z-axis smaller than the z of the one quad .(if i didn’t describe it clearly, i think a mail with pics can do it)
    Thus, i wonder that if the quads batch is really easy-using in a RPG game which contains a batch of same-looking monsters and several hero roles running across the batched monsters….

    happy new year~looking forward to ur reply

  • lars says:

    @Gene: Check mail ;)



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">