Current UiStack based extraction potentially leads to poor batching

[james7132]

Bevy version

a3baf2ae869611a84cf1bc062c498ea08128cbd9

What you did

cargo run --profile stress-test --features trace_tracy --example many_buttons

What went wrong

Issuing 24,000+ draw calls when it could be issuing 3.

The construction of UiStack forces siblings of a similar depth in the hierarchy to be non-adjacent if any of them have children. This also forces their descendants to not be adjacent, which is breaking large scale batching.

https://github.com/bevyengine/bevy/blob/a3baf2ae869611a84cf1bc062c498ea08128cbd9/crates/bevy_ui/src/stack.rs#L93-L102

[ickshonpe]

I just had an epiphany about this.

The UiStack rendering order is correct. Most of the time it's only very inefficient in special cases like many_buttons where you have a huge number of UI elements arranged in a flat grid. But for these special cases there is an easy workaround, we can just give all the leaf nodes in the grid the same global ZIndex. That immediately doubles the FPS for me in many_buttons in release mode.

There might even be a way to do this automatically as leaf nodes are much more likely to be textured.

[nicoburns]

Most of the time it's only very inefficient in special cases like many_buttons where you have a huge number of UI elements arranged in a flat grid. But for these special cases there is an easy workaround, we can just give all the leaf nodes in the grid the same global ZIndex.

What if you have a large number of items arranged in a flat grid with a modal rendering over the top? I think this needs a more general solution (and my understanding is that such a more general solution is possible).

[ickshonpe]

Well, you just give the modal rendering an even higher Global ZIndex. But yeah, you are right, it's a hack not a solution to the overall problem.

[nicoburns]

It may be possible to solve this using depth buffers. From the Iced discord:

(https://discord.com/channels/628993209984614400/1027584473631555604/1075119353332248686)