I see that the canvas has a functionality to become a child of another canvas. When setting it, you inherit all of the values besides a couple which you can set manually (i.e. Pixel Perfect).
Are there any merits to having child canvas’s than having only one canvas and using empty Game-objects as folders to related UI’s?
I understand the concept of having sibling canvases b/c you would want to seperate a HUD from a game menu etc. (Organization wise and performance wise since it doesn’t redraw the entire canvas when only one thing changes.) But I can’t find a reason to make it a child.
Using one canvas, every single one of UI elements under the canvas is a subject of re-rendering, whenever one of them is marked dirty. By spreading them into different canvases, you can effectively decentralize such risk of re-rendering.
For example, you may assign a different sibling canvas for the top-screen navigation bar, the main content view and the bottom-screen navigation bar respectively, so as to avoid re-rendering the top/bottom navigation bars whenever a layout inside the main view has been changed.
I spent several months developing a level editor for a game I am working on and while I cannot say for sure it does not have merit, it doesn’t appear to have special merit. In my level editor, I have two separate canvases, one for live testing and one for level building. These are very useful because I like to attach my UI scripts to the different canvases so when I disable one canvas, all the scripts and child objects also are disabled.
The way I see it is that if your Canvas info is the same then you really don’t need them to be children of each other. Just simply combine them. Canvases are meant to be all encompassing objects. If you subdivide your canvases you might end up losing track of what belongs to what.
I found that have a child canvas allows you to set different rendering sorting layers for its children. Theoretically, the transform order should allow you to set the renderering order, but sometimes it doesn’t seem to work for me. That’s when the child canvas helps out.
Since there’s no accepted answer and this comes up quite high in Google Search, I would share the link toward the answer to the question: Link to the Source
Simply put, the benefits of nesting canvas (putting canvas as a child to another canvas) is based on the complexity and content of your UI. While obvious, the importance is more in the division of the UI than the amount of UI element itself. The key point to remember is that nested canvas are isolated from their parents. When anything in a canvas is changed, it’s become “dirty” and the GPU will be requested to refresh the Canvas’ content in the next frame. It refresh absolutely everything in the canvas (even disabled elements). An isolated nested canvas would means that anything under it will refresh, but nothing from its parent’s canvas (as long as those doesn’t change too).
An example of how to set up this is in a classic gameplay UI. You might want to keep the constant backgrounds like the frames and filling bar (not the filling itself) on a canvas and all the stuff that updates in real-time during the gameplay in other canvas (the numbers, filling, 3D maps, etc.) that are children to the parent canvas that has the constant content. If you would allow, me the saying, it’s better to sandwich the dynamic contents in a canvas between 2 constant canvas than to make all those into a single canvas.