Include UI node size in the vertex inputs for UiMaterial.

[viridia]

Objective

Includes the UI node size as a parameter to the UiMaterial shader, useful for SDF-based rendering, aspect ratio correction and other use cases.

Fixes #11392

Solution

Added the node size to the UiMaterial vertex shader params and also to the data that is passed to the fragment shader.

Migration Guide

This change should be backwards compatible, using the new field is optional.

Note to reviewers: render pipelines are a bit outside my comfort zone, so please make sure I haven't made any mistakes.

[cart]

I think the most controversial aspect of this is bandwidth usage. Each piece of vertex data we include reduces the number of UI widgets we can draw in a frame. We're now encoding writing/reading four copies of the same vec2 for each node. Given what I've seen on sprite benchmarks, this will likely show up in a reasonably big way on UI benchmarks.

[viridia]

@cart What's the alternative?

You are right that we don't need this information to be repeated, it could be a uniform.

But we do need this info to be accessible in some fashion - without this, UiMaterials aren't very useful, or at least, I can't think of many use cases that don't require knowledge of the size.

Yes, you can get around this by having a separate ECS system that measures the size of each node and updates the uniforms, but now you have to have a separate instance of the material for every widget - which I imagine is even less efficient than having extra per-vertex data.

[JMS55]

If we really wanted a performant UI renderer, we would use storage buffers to pull UI data from instead of repeating it per-vertex. For now, I'd rather focus on getting a usable and feature-ful UI system, and then come back to performance later, personally.

[cart]

What's the alternative?

The alternative is splitting the pipeline / breaking batches for things that need the size, so we only pay the price in the cases that need it (although the cost of rebinds from splitting the pipeline might outweigh the data read/write costs) . And/or switching to storage buffers as @JMS55 mentioned. However we can't use storage buffers on WebGL, so we'd need a fallback.

Fortunately I just ran the many_buttons benchmark with 100,000 buttons and this change (surprisingly) didn't show up meaningfully for me. I'm down to call it a wash for now and we can revisit later.