Performance spike when toggling UI

[belgarion01]

Hey!

I'm doing an inventory like Terraria which can open/close with a button. I've a GridView which handles 40 ItemSlot. Each of those ItemSlots is an ItemView. The thing is, everytime I close or open the inventory, Nova seems to take 20ms to activate/deactivate UIBlocks. All I am doing is call SetActive on the gameobject with the GridView.

Am I doing something wrong? Is there a way to "hide" my inventory instead of activating/deactivating it (like the CanvasGroup in Unity)?

I've attached a screen of my profiler when I'm toggling the UI.

[adgray1]

The first thing that stands out in the screenshot here is Deep Profile is enabled. Deep Profile tracing is rather resource-intensive and can substantially increase the measured frame-time of every function call, which means it's often not representative of the actual execution time with Deep Profile disabled nor release builds. So we'd expect to see a pretty significant improvement in performance with Deep Profile mode disabled.

Beyond that, if Burst is disabled or if you're using the free trial version of Nova, which doesn't support Burst compilation, then that will also negatively impact performance. If you're using the full version of Nova, can you verify Jobs -> Burst -> Enable Compilation is toggled on in the menu bar? We'd expect to see yet another large performance boost once Burst compilation kicks in!

[belgarion01]

You're right, Deep Profiling was growing the number here. I have tested in a build, and I have 1.5ms when toggling 40 ItemSlot, each of them having 4 UIBlock. I've Burst compilation enabled. But still, 1.5ms is still a bit too much for me for 40 objects. Do you have any workaround or advice? Thanks!.

Edit: Yes I've the pro version

[adgray1]

Another optimization that could be made is ensuring your scripting backend is set to IL2CPP, rather than Mono, which you can change under Edit -> Project Settings -> Player -> Other Settings -> Scripting Backend. IL2CPP will incur (typically) longer build times but better (typically) runtime performance.

However, given that in-editor and runtime performance can vary widely between devices/hardware, 1.5ms doesn't sound far off from what we'd expect here. Some work is done for each UIBlock whenever it's enabled/disabled, either directly or because an ancestor was enabled/disabled, so that 1.5ms is actually a measurement of 161 object activations/deactivations (40 * 4 = 160 and then +1 for the GridView itself). It's not 0ms, but a lot more work would have to be done on the same frame before that 1.5ms starts to contribute to any noticeable impact on framerate.

Currently Nova doesn't have a "hide" option, like you're describing, so please create a new feature request if that's something you'd like to see Nova support in the future! Thanks!

[belgarion01]

Thanks for your answer, I really appreciate it! I'll check my scripting backend tomorrow. If 1.5ms seems normal for that many object, I'll try to reduce the number of UIBlock. For the context, 1.5ms is fine for PC, but I'm afraid about devices with less power (Mobile, Switch...).

A little experimentation: I was toying around with the Clip Mask to "hide" the inventory and I had no more issues with the framerate. The catch was that I still could interact with the slots. I'll try to disable the Interactable component when the inventory is hidden tomorrow.

You've answered my question! Your asset and documentation is really comfortable to use, thank for your work. If my workaround is somehow working, I'll post it here for anyone interested.

[adgray1]

Happy to help and glad to hear you're enjoying using Nova!

If you want to try using the ClipMask approach, you could add an invisible UIBlock that matches the GridView's size/position and add an Interactable to it configured to block input. This invisible/input-blocking UIBlock must also come after the GridView in the hierarchy, as that will give it higher render priority - if it comes before the GridView, then the GridView objects will still technically be considered "rendering on top" and will continue receiving input.

[metallibus]

I'm running into a pretty similar problem in my current project, but the outlined solution and other tips from @adgray1 don't fit my use case and I've been unable to come up with a good workaround here.... I'm curious if there's something I'm missing or if anything else has been added in the time since this question was asked.

My issue is a little different, in that I'm trying to display a bunch of "balloons" over a game world... more akin to something like an RTS game with floating health bars, except that mine are comprised of ~40 different elements each, and I'm sometimes trying to render ~30-50 of these at once. Nova seems to be able to handle rendering them well enough, but when zooming or panning quickly, I'm hitting issues with this same type of show/hide problem.

My initial strategy was to pool/recycle them as the user pans, and gameObject.SetActive(true/false) as I reuse/free them. But with the complexity of my hierarchies and the number of elements I've got, fast zooming etc can trigger activate/deactivate calls totaling 15-30ms in a single frame... Which really butchers the smoothness. (This is standalone builds running on medium-tier hardware)

As outlined in this post, this amount of time for my amount of complexity isn't outlandish, so I've been trying other things... Mainly, I've tried moving them "off screen" instead of deactivating them, and while this avoids the massive spikes, I get stuck with this OverlapJob which seems to keep running on those offscreen objects:

While this isn't the worst thing that Nova alone is taking ~4.5ms per frame, it seems silly to keep paying the cost of "every balloon I might ever need to show simultaneously ever" every single frame - even when I'm at a point where I only need a handful and the majority of them aren't even being rendered. In my versions where I deactivate them, these same Nova calls drop below 0.5ms.

Is there some way I can "remove" them from this process? I've tried things like shrinking, masking, spreading them over different Z indices, but can't find anything that will reduce the runtime of this job.... I know and/or don't care if they overlap, yet I can't find any way to indicate this or short-circuit this to Nova. In that job I see stuff about ZLayers and SkipRendering but it seems that flag is specific to things like drop shadows etc.

Do UIBlock3D / world space blocks possibly get culled better than UIBlock2D / screen space? Is that possibly a better avenue here? I've avoided making that switch because it's much tougher in my use case, but might bite the bullet if there was known to be better culling there or something.

I'm shocked there's no "don't render this thing" in Nova anywhere. It's a pretty basic and universally useful tool for a UI toolkit, and you guys have lots of features here. I understand Unity heavily leans on SetActive but as such, that call becomes very heavy handed and there seems to be lots of Nova activation/deactivation logic happening there as well.

[belgarion01]

I'm not sure if it can fix your problem but here is what I ended on: I accepted this little overhead on my inventory but I had a backup that I tested if it would become a problem. Instead of show/hide the inventory, I move it inside/outside of the screen which result in the same way. But since I don't use SetActive, OnEnable is not called and I don't have those extras operations running.

[metallibus]

That's what I've sort of been attempting, but in my case, the overhead of this "workaround" is pretty crazy. I'm wondering what other possibilities there may be.

I've been considering things like pushing the elements to a different sort group, or different sort groups from each other, switching layers, and a few other things, but I've burned a bunch of time on this and nothing seems to "exclude" these from the batches considered for the OverlapJob and other rendering passes, so nothing is really reducing this overhead.

I'd like to know if any of the authors/devs have any ideas here so I'm not spinning my wheels building a bunch of different systems that end up not working.

[belgarion01]

I think that if you want answers from the devs or other users you should create another discussion. This one is old and marked as "resolved". If you don't want to loose history of this discussion, add a link to it in your new discussion. Have a happy new year!