[2.1.7] Large rendering performance regression on Linux

[Rseding91]

Gleba is problematic because several decoratives are configured to render in the same layer as trees, and trees are in their own atlases for the shader effects. The design of Gleba goes against batching in general - it wants several layers never meant to interact to interact.

[Harkonnen]

making those decos "trees" with wind effect of zero might work (via 'if' or 0. multiplier) to unify organic shader. you can also animate them this way

[SteveofDoom]

The most bizarre thing to me is that it's a 2.1-specific issue. I've never had framerate issues prior to 2.1. I would think texture arrays are a given with the amount of sprites this game has.

according to FFF worms got revamp on 2.1, could be an issue. on texture arrays - back in those days they were abandoned for hw limitations, probably still is

Everything you are saying makes sense, but over 40x increase in draw calls (Vulcanus case) seems a bit excessive from such a change even though I know nothing about Factorio's codebase.

Gleba is problematic because several decoratives are configured to render in the same layer as trees, and trees are in their own atlases for the shader effects. The design of Gleba goes against batching in general - it wants several layers never meant to interact to interact.

Is there something about rendering Gleba that changed compared to 2.0.x? I haven't really noticed any difference visually (except stromatolites ofc), but definitely noticed the performance gap and it's all about decoratives.

[Harkonnen]

When things are interleaving frequently on a boundary of 40'000 batch call, that'll be the case. Speculations on decoratives are based on this https://factorio.com/blog/post/fff-442