MaskableGraphic cpu and memory usage

Unity Engine
1

Hi,

We are having a heap of performance issues with 5.2 both CPU and memory usage for doing simple things is absolutely crazy (currently working on patch 3 to fix the terrible per frame outline performance).

We have a ui with a list of dungeons - each dungeon in the list is a prefab which is instantiated and inserted into a SrollRect - the dungeon prefab has maybe 15 elements (a mixture of text and images). To open the UI with 10 dungeons causes a spike of around 250ms and about 4 meg in allocations.

There are several factors contributing to this hit but in many cases the biggest problems seem to originate inMaskUtililes:

Rebuilding the layout - 1meg allocation in MaskUtilities.FindRootSortOverrideCanvas:

2337383--158008--upload_2015-10-13_14-27-13.png
2337383--158008--upload_2015-10-13_14-27-13.png967×197 51.6 KB

Much of the CPU time is spent generating the mesh for the text (some of which is outlined)

Instantiating our 10 prefabs allocates 2.5meg and take 80ms

2337383--158009--upload_2015-10-13_14-34-49.png
2337383--158009--upload_2015-10-13_14-34-49.png772×67 17.6 KB

This stuff was working quite nicely on mobile in 4.6 and in 5.2 it doesn’t even work nicely on a powerful pc.

What gives?

If this is something that someone might actually look into then I can see about making a cut down example (the last time I did this no-one ever touched the bug so I am loathe to waste my time if this is also going to go into the unity bug database blackhole)

2

In the end i did put together a repro case yesterday and sent in a bug - still waiting to hear back that the bug has been received - how long does this usually take?

3

As far as I can tell you should get an automated e-mail within minutes after sending the bug. Check your spam/junk folders to be sure.

4

Amazing - It turns out that uGUI is completely unsuable ‘by design’:

“The CPU and memory spikes are by design, because when we generate UI elements we have to do batching, so it takes more time to process. As this is not a bug, I’ll close this case.”

I mean I get that it needs to do something, the point is that the way it is being done is clearly not working, but no just ‘your issue has been closed’. Not really going to encourage anyone to report anything else as broken is it…

5

That reminds me of Microsoft’s suggestion to improve WPF’s perceived Application Startup Time:

6

I’d like to link another forum thread i raised related to this issue: Graphic.UpdateMaterial memory allocations - Unity Engine - Unity Discussions

Seriously though, perhaps this is __currently by design__, but if the current implementation does not provide the necessary performance, it should be revisited, and hopefully this can be a more open process.

The managed part of the UI framework is open-sourced, and i suppose there could be many different solutions proposed by the community, so i think that just “closing” this issue and not having a second look is not the best solution.