2 questions on UI Toolkit

Unity Engine
, ,
1

Straight to the questions :slight_smile:

  • If I want to have multiple interfaces in the game, let’s say, one for pause menu, one for gameplay UI, one for main menu etc, which approach is the best performance-wise:
  1. Having multiple UIDocument files and switching between them in one UIDocument component
  2. Having multiple objects with UIDocument components and respective UIDocuments assigned and turning on/off those objects
  3. Having one UIDocument with different interfaces grouped under their own VisualElement and changing the group visibility by changing the visibility of the parent element?
  • Should I use textures or sprites when putting them on UI? Again, performance-first.
2

Also, it would be cool if someone can rate methods from question #1 by performance cost. I have some personal preferences, just wanna see if they meet tough reality.

3

Hi @ - thanks for these questions.

The UIDocument component basically manages the existence of a VisualElement within a Panel. If your UIDocument components all reference the same PanelSettings asset, they will be grouped in the same VisualElement tree at runtime. In the Editor, every EditorWindow has a Panel.

  1. Both 1 and 2 will have the same performance characteristics. They both make a structural change in the shared VisualElement tree (physically add / remove the VE from the hierarchy). 3 will be best for performance, as it operates on styling, not structure.

You could add a 4th option for flexibility: have multiple objects, each with a UIDocument component pointing to their own separate UXML asset (e.g. one .uxml file per screen), all referencing the same PanelSettings asset, and manipulate the rootVisualElement style to control their visibility. This way you keep things modular (different UI assets and objects per screen/HUD element), but still good performance by reusing the same PanelSettings assets.

  1. Both textures and sprites will have similar performance. I believe there is a small initialization overhead with Sprites when building the geometry, but we could optimize that away in the future.

Hope this helps!

1 Like
4

huge thx

5

@etienne_unity also, wouldn’t your method add additional performance costs since I’m keeping all the documents active?

6

The overhead of method 4 vs 3 is extra GameObjects with Transform and UIDocument components on them. What you get in return is flexibility on how you assemble your final set of screens.

For example, if you need to split your UI in multiple assets to manage your build size, you can use method 4 to make asset bundles and assemble them as needed at runtime.

Once assembled, since they all share the same PanelSettings asset, runtime performance will remain high.

7

@etienne_unity
Oh, I see. And what about nesting multiple UXMLs into one base UXML, and then switching them on/off?
That should would like a method 3 performance-wise, but also give me a flexibility like method 4