How to avoid the cost by the Update() in UIRect

[me]

Hello guys, as we all know that the Update() method would cost some of the performance. If only one, that is not a problem, it costs only a little; but if 100 UIWidget, they will cost a lot.
How to avoid the cost by the Update() in UIRect.

[me]

I did an experiment on mobile phone before. execute an empty Update() method would cost 0.005ms~0.007ms (60FPS). If 100 UIWidget, 100 empty Update() method would cost 0.5ms.
But Update() is the method in UIRect, I can't stop it. Could you tell how to solve this problem in another way ?

[Nicki]

You cannot reasonable avoid the actual call to Update in UIRect, save make your own custom Update which only updates the UI at given intervals instead (say 0.5 seconds).

In all honesty, this would be the wrong place to try to optimize anyway, the overhead in Unity making the call to Update is almost negligible. It's likely that the time you're seeing is the result of measuring that time, not the actual Update call. How did you measure?

[me]

Thank you first !
I use the Unity-->Profiler to debug the cost of the Update() method.
I rarely used Update() method in my codes. For example, when i worked with the pack, there would be hundreds of ItemIcons in the pack. The ItemIcon was made up of the UIWidgets, and there is no Update() method in it. When i ran the pack view, the performace is very bad. I debug in the Profiler window, i saw that the UIRect.Update() cost a lot.

[r.pedra]

Are all your sprite activated? In our project, we have a level selector screen, with 140 levels and each level selector is composed of multiple widgets, so it has lots of UIRect Updates.
The thing we notice is that if we run a script that detects if the widget is in the screen every X seconds (depends on your needs), and disable unneeded widgets out of screen, it saves us a lot of Update.
But really, the Update function of UIRect is not very heavy.

[ArenMook]

Deep Profiling never gives accurate results. I've explained this many, many times on this forum.

[r.pedra]

He didn't say he was using it

[Ferazel]

Yeah, I just want to stress that the UIRect.Update is not insignificant. I was working on a pretty UI heavy game and had 4-6% of frame CPU for UIRect.Update() with 8-10% for the UIPanel.LateUpdate() without deep profiling. It is a problem that NGUI devs need to be aware of and to know how to reduce. Looking at the code the best option right now are to reduce the active UIRect count, reduce Update() anchor calls, and finally avoid fixed aspect ratio on sprites/textures.

Ideally, I would imagine that the the NGUI panel would keep a collection of all of the UIRects that needs to be updated and remove the ones that don't. Then there would be an Update() at the panel that calls the OnUpdate() on only the rects that need updates. This would reduce the per frame overhead associated with essentially unnecessary logic checks and Update() calls.

[r.pedra]

You need to think about the cost of such detection.
If the Update of the panel detecting if a widget needs to be updated cost more than the update of the widgets, it would be worst.
Moreover how do you consider that a widget don't need to be updated? If an object on the screen is anchored on an object out of the screen, disabling the update could break the anchor(I don't know exactly how works the anchor so I may be saying shit)

[Ferazel]

From what I'm seeing in the code there are only some flag checks and editor checks that are performed in order to determine if a UIRect.Update has any work to do. These are if the anchor is set to Update(), if the editor not in play mode, if the sprite/texture is set to fixed aspect, if the sprite is animating or if the sprite was changed. Most of these checks can be boiled down to a simple flag that is set on the widget to tell the panel that it needs to be re-evaluted for receiving the Update(). Then in the Panel's UpdateWidgets() it could re-evaluate the widget's update need and manage the list there for the widgets that need them. I could be wrong as well. Regardless, it's only a suggestion for Aren or whomever to consider.

[me]

Thank you very much .

I wish that the UIRect.Update() methods are executed only when they need. Also I wish NGUI will become a stronger and faster UI system.

[me]

From what I'm seeing in the code there are only some flag checks and editor checks that are performed in order to determine if a UIRect.Update has any work to do. These are if the anchor is set to Update(), if the editor not in play mode, if the sprite/texture is set to fixed aspect, if the sprite is animating or if the sprite was changed. Most of these checks can be boiled down to a simple flag that is set on the widget to tell the panel that it needs to be re-evaluted for receiving the Update(). Then in the Panel's UpdateWidgets() it could re-evaluate the widget's update need and manage the list there for the widgets that need them. I could be wrong as well. Regardless, it's only a suggestion for Aren or whomever to consider.

Thank you for your suggestion.  I had no  good idea before so I came here for help. I will take you advice into account. Thank you again.