Background
I reported back in April, 2022 that I had found a crippling problem with how the UI Toolkit was reacting to visual elements being shown and hidden. As discussed here, this was demonstrated at that time by two phenomena:
- The vertex count would skyrocket into the millions and not come down.
- The draw call count would also go into the hundreds range and not come back down.
Your team reviewed the bug report and eventually suggested problem #2 was due to how the profiler was calculating vertices, and it would be fixed. I was also told there was a deeper change in how the UI Toolkit would be rendering so we needed to wait for that to see about #1
I have downloaded Unity 2022.2 and while I can see it no longer gives abnormal vertex counts, the problem of massive draw call accumulation is still occurring along with heavy performance problems from this.
The Ongoing Problem
Using the exact same project from the prior bug report, here is an initial state of the app showing enough visual elements to add up to around 160K vertices. Despite the large number of elements, it is only running at 7 draw calls and 7 batches which is still quick and responsive:
The test project is designed to show or hide (toggle) a large number of the elements each time you click. Here it is after one click with a large amount of elements hidden, now showing 7.6k vertices:
Despite showing fewer vertices, we now have 79 draw calls and 12 batches.
If we click again to toggle back to the initial state showing the full vertex count and elements, here is what we get:
Now we have 122 draw calls and 48 batches despite showing the same vertex and triangle count as on start up (same state).
Significance
I believe this was not (and is still not) a cosmetic or superficial issue. I am now around 19 months into my app development and I have optimized every aspect so far I can. However, despite every optimization I still cannot get a simple scroll window to scroll smoothly. I think this is because by the time I toggle around panels within the app (ie. navigating from a user perspective) to get to a typical scroll window in the UI, I am already at 150+ draw calls.
I would very much appreciate a reassessment of this still ongoing problem. If there is no obvious solution to your team, I wonder if you can speculate on why this is happening and share the potential reason. Perhaps there is some workaround we can develop.
I don’t mind using Reflection or other tools if I had to. For example, I built a custom text input field using Reflection (with some suggestions from your staff on the forum) since the character positions were not publicly available in the Label or TextCore TextGenerator classes. I don’t mind putting work in myself to solve it if there is any way I can. I need this to work. I cannot permanently have 150+ draw calls and the app barely chugging along every time a user toggles some elements or a UI panel on/off.
If we even had some way to trigger a full “redraw” or “reinitialization” of the draw call system periodically (similar to how we garbage collect) perhaps this would be a manageable solution. I could monitor the draw calls presumably and every time they get too high, trigger a reinitialization. Or just run one whenever the app is visually at rest or after a large panel is shown/hidden.
I appreciate any solutions you can provide.
New Bug Report: IN-25597
