Unity UI UI Text High CPU Usage (2017.2.0f3)

After updating to Unity 2017.2.0f3 today there is all of a sudden a massive rise in CPU uses on UI. I have made a small script which instantiates a new text gameObject every frame that demonstrates this. Which results in the profiler looking like the image below. About ~500 Text components are instantiated.

This same test was replicated in Unity 2017.1.1p3 and there was little to no change in CPU even after ~500 text components, I'm still getting a solid 60fps.

I have reported a bug to Unity.

I will also attach a package so other people can try this out and post their response. Hopefully I'm not the only one with this issue.

 

Confirming. Our MainMenu now requires 200ms (yep, it's 5 fps) to update Layouts. On 2017.1.1 we had ~85 fps.

 

I have noticed that EventSystem.RaycastAll() is taking a long time to process, double what the rest of the game takes only helps If I disable the objects and not just use a canvas group to hide and stop them from being interactive. Even then with all the UI elements on the screen disabled from being interactive the profiler still shows most of the time taken with the raycast to the UI.

I also get really bad performance with layouts most of which is happening during rebuild which is happening every frame, which shouldn't need to happen if the components children haven't changed.

 

This bug was present for quite a while in the beta releases. How it made it all the way through to full release is honestly beyond me.

 

I've also been surprised by the spike in RaycastAll() calls in the latest version.

 

Yes I am quite shocked the latest release slipped through QA. Maybe they don't test for performance and only test for added features' bugs. Or Maybe they don't have a QA department and rely on their beta community. I'm not sure. Which ever it is this should still be in beta.

I wish I had time to be apart of the beta community, but sadly I have to make a game so I need stable, even changing to .NET 4.6 was a mistake on my part, but I'm too deep now, going back through all the syntax changes would take ages.... boo hoo, poor me lol

 

It is, and was, a known issue and is reportedly expected to be fixed in the first patch release -- archived thread (doesn't allow replies anymore) is here: https://forum.unity.com/threads/ugui-rendering-updatebatches-performance-regression.496849/

We too are anxiously awaiting the patch release so we can move to 2017.2 -- lots of great things in the new version, but how it can be of use to anyone with 100ms+ UIs is a bit beyond me (maybe games w/out any UIs? Not sure)...

 

I have actually just switched over all my text components to TextMeshProUGUI components and performance has gotten a lot better. I wish I got onto that asset earlier, it is really sharp.

 

Just to remind you that TextMeshPro looks sharp because they uses a different shader (Valve's Distance Field algorithm) from other normal uGUI. (So it require pre-processing the font file to make a texture data suitable for that shader. It is not just a simple pixel anymore)

What this means is if you have a stack of uGUI and then you have TextMeshPro in the middle of it, every TextMeshPro would break the batch and increase your draw call. Putting TextMeshPro in the same depth as possible or put them all at the top to minimize the switching material cost. (They also give you one more special material that ensures TextMeshPro will be drawn last regardless of sibling index)

 

Text is usually on top of everything else, so having one in the middle would be counter productive to the user being able to see it. With that being said I have multiple TMPro objects in my UI shown at all times and even more with other screens showing. While the game is running 13-20 set pass calls are made and most of them comes from the game not the UI. Thats with 100+ objects in the scene and quite a few in the UI.

Despite what some have said about uGUI, I find it has very little allocations in a build. In the editor that is a different story, same with the performance problem that has been found with this thread. It vanishes in the build, at least for me.

 

uGUI's Text will break the batch as well, because it uses a separate dynamically-generated texture of font glyphs.

 

We still have a mix of TMP & UGUI text controls -- former for all world space stuff and some UI, latter on some legacy UI stuff.

The issue we're seeing here isn't draw call related though, it's almost exclusively layout -- see my post in the linked thread for more details. I did try some things with this, like disabling all (UGUI) text Components, and even all text (TMP & UGUI) components, replacing them with images, etc...

It really is a Layout issue, though -- the only ways I was able to make gains against the performance regression were by reducing the GO counts that were under the ContentSizeFitter/LayoutGroup elements that were at issue (GridLayoutGroup, Horizontal/VerticalLayoutGroup, etc.) OR via disabling the ContentSizeFitter and writing custom code to determine appropriate height/widths. The latter was a workable solution, but the number of UIs we'd have to do it for (and thus the amount of custom "height/width setting" code we'd need to maintain) made this untenable except as a last resort.

For now, we wait.

 

Does it still do it in the build? Because I am not seeing the bad layout behavior in the build only the editor. Same with EventSystem.RaycastAll() performance in the editor, it is horrible, but not in the build it actually runs quite well in the build.

 

These are only editor issues.