Should i put a changing label inside its own panel?

[Arsenik]

Hello, if i have a label that change often, for example the text change often to take track of the score of the player, should i put it in its own panel?
Will this increase performance? Right now the label is in a panel together with 8 other widget.
I've been reading that widget that change often are bad, it's changing the text on a label considered "changing"?.

Changing the alpha o color of a widget is considered changing too? For example to change color of a button on touch. What are the best practices?

Thank you.

[Nicki]

Yeah.

If something changes, the whole panel is rebuilt, so it will get progressively heavier as you put more in there. If you keep it in its own panel, it costs you 1 extra draw call, but saves you rebuilding the panel every update (or how often you update the text).

I'm not 100 % on whether changing alpha / color counts as changed, but you can look into the UILabel or UISprite script and see if it calls MarkAsChanged.

[ArenMook]

All changes count -- whether it's alpha, position, or sprite changes.

[Arsenik]

Ok, thank you.
I have more quick questions:

1) Having many Anchor can be bad for performance? I separated Gameplay Buttons (constantly pressed by the player) and the score label from the rest of the gui, but to keep consistency in the gui layout i had to double the anchors... from 4 to 8. Is this bad? I'm targetting mobile, it's the change i did worth?

2) What about setting panel to static? The label say "check if widget won't move". With move you intend changing too? If so isin't better changing the label to "check if widget won't change"?

3) If i have a panel set to static, and try to change something, say alpha, i get some extra penalty (in performance?).

4) Instead of manually changing alpha when the user press the button, can i get a better performance using the builtin ImageButton and changing the texture?

Thank you for your great support

[Nicki]

1) yes, in theory. It has to calculate the position every Update so potentially, it can be costly. In practice you have to have quite a few before it has any influence. Test it in the profiler, or on the device by using the device profiler you can enable through xcode.
2) Look in UIPanel.cs for the details in LateUpdate(). Some times it will get "forced" to redraw, but mostly it just doesn't update if you change something. It saves the checks that look for movement changes, thus optimizing it.
3) No. It just doesn't update (ie. you won't see the change on screen).
4) I can't say for sure, but I think it's the same. It's a transparent shader anyway, so it has to alphatest for each pixel no matter what. Not entirely sure on that one though. To test it out, make 10000 sprites and change them all on the same button and just do a simple profiler lookup; change via alpha and then change via texture change - see which is faster.

[ArenMook]

4 -- no difference as either way you're changing something, causing the buffers to be rebuilt.