This bug is present in 5.2.0f2 through 5.2.1p3. The workarounds listed in the comments for the issue tracker do not work for us. This blocks our ability to use 5.2. Is it fixed in 5.2.2?
Likely not no, the fix hasnt been backported as I want some more QA testing done on it before a backport happens as the last time i tried to fix this i found a edge case early on that would have made things much worse. So i’d rather be safe then cause bigger issues.
The way i know to work around it is modify some property of a child CanvasRenderer when moving the canvas. Really anything that causes it to dirty the batch should work.
ok, that seems to work. I should ask though, as these elements kill our framerate when the camera moves: is this the most efficient way to be moving health bars around in the world if we want them to always face the camera and stay the same size? (they are screen space overlay canvas mode, with lots of child canvases)
umm likely not my suggestion would to not be using nested canvas’s but addition world canvas’s
ok, so our UI engineer should change all his nested screen space overlay canvases that compose the complex health bar to use one worldspace canvas, and then update the orientation to face the camera? I imagine there is some ui scaling component to keep them constant screen size? Should this reduce batches when the camera moves vs our existing nested screen space overlay canvas technique?
Yeah to many canvas kills your framerate, i have an alternative solution with just one canvas
@chrismarch_1 Yea i think thats likely what i’d do but i’m not fully sure what you are going for other than having a complex health bar.
fix is coming in 5.3b3
Can you elaborate why using nested canvases is bad? Coz it seemed always to be a recommended solution for a moving element inside your UI.
Because the canvas comes with allot of extra rendering and calls, example RenderTransformWorldpacesync. Better to just use a Gameobject as child, and move that. Its a performance issue, specially with moving elements…
Also because we have a bug right now with nested canvases not updating the childrens rendering position correctly.
But just using GO without Canvas will lead to infamous Canvas.BuildBatch every time GO moves… Or I misunderstood what you’re proposing.
True but is BuildBatch that big of a issue still now that is been optimized and threaded?
Idk, still didn’t move to 5.2 due to bugs 
But you’re implying that with 5.2 you can move UI elements without worrying about BuildBatch even inside Canvas with big hierarchy (many UI elements) where previously it would kill performance? That would we great for workflow 
Edit: will have a big test when 5.2.2 is out
Thats my implication yes. I’m hoping your big test will prove it to be valid :). a bunch of stuff was done in 5.2 so hopefully you see the performance improvement we saw.
Hey there. Been following this thread. This issue is currently blocking us from updating to 5.2. Unfortunately our situation with nested canvases is that we’re using them to sort 3D particles correctly against 2D UI elements. So world canvas isn’t an option for us unfortunately. Any thoughts on other workarounds while this bug gets sorted? Or is dirtying the batch our only option right now?
its really the only option right now, the native side need to get notified that it needs to update so it can recalculate things.
Were you suggesting one world space canvas per health bar UI per object, or one world space canvas for all health bar UIs for all objects?
I’d like to have them all on one canvas so they can batch together, but changing the draw order to have the nearest on top with one canvas total for all health bars is spiking 60+ms CPU in Canvas.SendWillRenderCanvases when I change the draw order so the nearest are on top with Transform.SetAsLastSibling and similar. (That is just using a screen space overlay canvas)
If I am going to have 1 canvas per health bar, then I may as well stick with our current solution, to sort by Canvas.sortingOrder to avoid the spikes from Transform.SetAsLastSibling
The only use case I can think of for nesting canvases is to force change the layer ordering.
Maybe an easier fix to unity would be a component we can add to ui elements that allow for overriding the “hierarchy to layer order” auto layer ordering.
Coming from a web design background, nesting DIV elements is pretty normal, but so is manual selection of Z ordering.
1 Like