There is nothing to gain by improving this. It looks like it's submitting about 2500 sprites at a time, which means the draw call overhead is about 0.04% of the naive case of one call per sprite. If we increased this to say 5000, it would make such a tiny difference it is totally irrelevant (0.02%), while increasing memory usage and latency. So like most engineering tasks there's a tradeoff here, and we've aimed at a good sweet spot.
I can understand why you're doing that, with a lot of sprites. Bunnymark is doing the same thing, only their limit is a lot higher. They are doing 3 draws for 60.000 sprites.
But in my game, I don't have a lot of sprites... currently 350 in layout, only a few on screen. But the draw and texture swapping is still apparent, quite a lot of texture swapping and draws for very few sprites, so even if the drawing workload is pretty small, for a mobile phone that's pretty weak, something is causing it to slow down. Even with just a few sprites on screen.
How to get around it? Can it be the texture swapping that has overhead?, Looking at the WebGL inspector, it's drawing a few sprites, switching texture, drawing a few more sprites, switching again, drawing a few more sprites, over and over like that, each frame, in multiple layers. Not even near 2500 sprites per draw. Maybe maximum 10. So there must be something causing the slowdown.
I imagine, if I were to put all my sprites into one spritesheet this wouldn't happen. I'm curious to try it on C3, as it's much smarter when generating the spritesheets, but I can't test this project there yet, as there's no photon cloud plugin so far.
Exporting from C3, I can see that even separate sprite objects are on the same sprite sheet, In C2 this is not the case.
So is it possible in C2 that the overhead is caused by the texture swapping, and unnecessary many draw calls due to that.?