Unity uGUI: Split Canvases Around Changes That Actually Occur

Identify the work a change triggers

A uGUI Canvas organizes UI rendering and batching. When elements change, Unity may need to regenerate affected geometry and reconsider the Canvas's batches. A small changing label can therefore cause work beyond the label itself. Layout recalculation is another concern: it decides sizes and positions through layout elements and controllers. Diagnose the relevant work instead of treating every UI cost as the same kind of rebuild. [1][3]

Group elements by change behavior

Unity recommends separating static UI from frequently changing groups. A child Canvas maintains its own geometry and batching, isolating that rendering work from its parent and siblings. Nested Canvases use their parent's render mode. [1][2]

Draw a small map of actual changes before splitting: which elements animate together, which change only when a menu opens, and which remain fixed? Give related changes a useful boundary. Creating a separate Canvas for every icon can fragment batching without solving a meaningful invalidation problem. Evaluate the resulting batch count and CPU work together.

Design an illustrative cockpit display

Consider a cockpit with a decorative frame, fixed labels, a fuel number, and an animated warning strip. Keep the frame and labels on a mostly static Canvas. Put the fuel display and warning strip in a smaller dynamic group if their observed changes justify that grouping.

Suppose the design requires the displayed fuel value to refresh every 0.1 seconds. Update that presentation only when its displayed value changes; the underlying simulation can keep its own timing. Reserve sufficient width for the intended number format so the label does not need to push neighboring controls around. These are proposed design choices, not measured savings.

Inspect layout dependencies separately

A Layout Group controls child sizes and positions using reported minimum, preferred, and flexible sizes. Text can influence its preferred size, and a Content Size Fitter can resize its own element from that information. Follow that dependency chain when a text change moves a larger panel. [3]

A Canvas split is a rendering boundary, so also inspect whether layout controllers still connect the changing content to surrounding controls. Remove unnecessary nesting or give stable regions a deliberate layout contract. The normal marked layout rebuild is deferred until before rendering, allowing changes to be processed together; avoid demanding immediate recalculation without a concrete need. [1][3]

Validate the interaction and rendering tradeoff

Capture the interface while fuel changes, a warning animates, and the menu opens. Compare CPU rebuilding and layout work, batches, and visible correctness before and after the proposed split. Check supported resolutions and longer localized labels. A cheaper idle screen is insufficient if opening the menu still causes the costly change.

Remove Graphic Raycasters from Canvases that require no input, and disable Raycast Target on decorative graphics where appropriate. This reduces unrelated input work; it does not substitute for fixing rebuild behavior. Keep splits whose measured benefit justifies their added hierarchy and rendering complexity. [1]

Sources

1. Unity UI performance optimization tips — Unity Technologies.
2. Canvas — Unity Technologies.
3. Auto Layout — Unity Technologies.