ps.batchable = true; drops FPS on Starling 2

[tadeubas]

Testing with 27 PDParticleSystem (fire fx), I got 40fps with 27 draw calls. Adding the line ps.batchable = true;, fps dropped to 30 and still got 27 draw calls. After adding the line ps.parent.blendMode = ps.blendMode;, fps was around 31 and I got 1 draw call.

Is this the expected results using batchable?

I am using Starling 2.3 January release version and this extension latest version.

[PrimaryFeather]

I'm explaining the reason for the batchable-issue in the wiki page (scroll down to "Batching"). So this is just how it works in Starling 2. In 1.x, batching would recognize automatically that these objects could be drawn together, but this had a few very error-prone side-effects — thus, I simplified the logic in Starling 2, with the downside of a few missed batching opportunities.

As for the FPS, this really is a little weird. Are you sure you were running a release version and had starling.enableErrorChecking deactivated?

[tadeubas]

Hey @PrimaryFeather I've created a fork of the extension, this way you can test it!

Check that out: https://github.com/Tudumanu/Starling-Extension-Particle-System

More FPS without batch... using RELEASE mode, tested with FP_28_sa_player and FP_28_debug_sa_player

[PrimaryFeather]

Thanks a lot, I'll have a look at it!

[PrimaryFeather]

Sorry for the delay — but today, I finally found the time to look into it.

The reason for the performance issues you are seeing is that the particle systems contain too many particles. Each of the particle systems creates about 200 particles — which means that batching will hurt performance. Here's why:

If batching is disabled, the particles are drawn directly from their original buffer (the one that the particle system class manipulates). This means one draw call per particle system (some overhead), but is very straight forward.

If batching is enabled, the particles are copied from their original buffer to a render buffer, and that buffer is rendered when there is a state change (or, in your case, if the maximum buffer size is exceeded). This avoids the overhead of many draw calls — but copying will occupy a lot of CPU time.

In other words: if the number of particles per particle system is too high, batching will hurt performance. The same is true e.g. for TextFields — that's why they, too, default to batchable=false. As a rule of thumb, I'd use batching only if there are below ~20 particles (quads).

To prove the point, I changed your code so that it runs with 30x30 particles-systems à 20 particles. Without batching:

With batching:

Here, batching actually helps a lot.

I hope that explains it better! :smile:

[tadeubas]

"To prove the point, I changed your code so that it runs with 30x30 particles-systems à 20 particles."

Can you share the code changes with me plz? I can't understand how you created 900 particle-systems with 20 particles.

[PrimaryFeather]

I can't understand how you created 900 particle-systems with 20 particles.

Haha, yeah, that would be a feat, right? 20 particles each, of course. Sorry for the confusion. :wink:

for (var j:int = 0; j <= 30; j++){
    for (var k:int = 1; k <= 30; k++){
        var ps:ParticleSystem = new PDParticleSystem(myConfig, myTexture);
        ps.x = 10 + 20*j;
        ps.y = 15*k;
        ps.capacity = 20; // limit max particles
        ps.start();
        sprite.addChild(ps);
        Starling.juggler.add(ps);

        //batch
        ps.batchable = true;
        ps.parent.blendMode = ps.blendMode;
    }
}

[tadeubas]

Thx a lot Daniel! I think we can close this issue, marked as explained/solved :smile:

[PrimaryFeather]

You're welcome! I'm glad I could help. :smile: