Simple question but a lot of detail. The VisualElement in the UI Builder Hierarchy is, well, very interesting. For example, in the root VisualElement or the so called Parent, has the Font Size in percent, this will dribble down to the children keeping all fonts at the same size but if it is not done at the Parent it does not work.
How many VisualElements can be used at any one time during runtime?
Thanks - Please review the attachment for details…
Hello!
Could you explain what you mean by “it does not work”? The font-size is an inherited property, so it will propagate to children by default, unless the child overrides this value.
There is no hard limit on the number of elements that can be added to a hierarchy. Just keep in mind that more elements require more memory and more processing for layouting, styling, rendering, etc.
As for the flex-direction setup question, remember that flex-direction affects how the children of the element will be layout inside it, and not how the element layout itself in its parent.
What I mean by it does not work, depends on the technology being used. UI Builder → Preview → Play Game → Build Mac App. The bottom line, it does not work happens in the build. I have to admit, I am still learning and interpretation might be subjective, so please take this with a grain of salt.
In the subject,There is no hard limit on the number of elements that can be added to a hierarchy. Having all these VisualElements on the screen, does clicking into the game itself beyond the UI Screen have any affect on performance?
The flex-direction row was an observation simply picking a FLEX attribute and testing the parent - child relationships and then expanding this and other test to USS files as well (not yet tested). Many of my questions cannot be answered by searching through Unity’s Manual. So. I test, test and test…
Thanks
I would expect this to work of course. Looking at the player logs might give some hints why this isn’t working. If you can share your project here, we could have a look as well.
Click events that occur on an element will be dispatched to its hierarchy. I wouldn’t expect any performance hit when clicking outside an element.
If the center VisualElement is empty while clicking through the emptiness of the VisualElement into the game, for example, changing the camera’s orientation, then this too the element being the VisualElement and the Game are both affected.
The important question then, is it possible to click into the game through an empty VisualElement?
Or is there a better way (method) for flex manipulation other than the screen displayed previously shown in the one-page focus problem giving the same result with no VisualElement in the center.
(I hate Apple’s Auto Correction)
As far as I can tell, a VisualElement will never prevent an event to get to the GameView. Even if you have a full-screen VisualElement handling click events, the GameView will still be able to handle Input.GetMouseButtonDown(), etc.
Great - Issue resolved… Moving on.
At mcoted3d
About The Font Size - as requested… It was not so much about propagation but about functionality… Please correct me if I mis-spoken.
Note… I did not add the Font Size to neither VisualElement nor Label except by using USS Class: Trying to size the font ONLY within the Label itself did not work…
Focused on: MainScreenPanel
Focused on: Label
Setting the font size to 20% means “use 20% of the inherited font-size value”. I think the default font size is 12px, so 20% of that will be 2.4px, very tiny.
Setting a font size in pixels (such as font-size: 20px; ) should give more consistent results.
I changed the unit from px to % in both cases… (hoping this would change the size of the font as the game resolution also changed…)
Please understand that I am learning… Any advice would be accepted. Thank you… I could have missed something from the manual. With that said…
Oddly, I too saw that same font size change after popping it into VE. Yet going back to the results on the build, it says it all. I will review this again in careful consideration.
The Font type and its attributes will be furthered studied… If you have anything else to add… Thank you.
It’s sometimes hard to understand how inherited values are computed. The UI Toolkit Debugger is very often useful to better understand the hierarchy and how styles are evaluated. It can be opened from the Window > UI Toolkit > Debugger menu.
Understanding is fortified with Experience and with that comes Confidence. Sorry, a little retrospection.
I went back and retested the Font Size only with the unit px____, my assumption from UI-003 where a general rule applies, the UXML parent tells how the children to behave… This is true with the unit px but not %. With that said, the latter, its functionality is not consistent when comparing other attributes with the same unit.
The class .font-size now works coming from the parent (MainScreenPanel) only.
