NGUI Update Optimisation

[r.pedra]

Hi,
I saw an article on Unity Blog that could be useful to NGUI:
http://blogs.unity3d.com/2015/12/23/1k-update-calls/

Maybe you already did something more optimized that what he is explaining, I don't know. Are you planning to do something like that if it helps NGUI runs faster?

Moreover, did you ever thought about the ETC1 + alpha system with NGUI?
You know that on Android ETC1 is a great compression format but it does not use Alpha.
We did a little workaround in NGUI Shaders and UIDrawCall.cs to handle ETC1 atlas + Alpha8 mask. (For a 2K textures, we freed about 10Mb of memory on the disk for a similar render quality).

[Shifty Geezer]

It's not worth it. You don't have 1000s of GOs created in NGUI.

[ArenMook]

The fact that having every script have its own Update() function vs having a single Update() in a manager that calls child updates has been like that since Unity's inception. It wasn't a secret, there just wasn't a blog post about it. It's the same about all functions. There is overhead every time C++ to C# boundary is crossed. Once you're in C#, it's faster to stay there if at all possible.

I tried it before but realistically there was little noticeable difference in performance and there were odd side-effects related to going from play mode to edit mode that were fixed by using Update() in widgets. Also note that if things are not visible you should keep their game objects disabled anyway, implying their Update() won't run.

If you want to go with the reduced Update() just to try it out, you can try it yourself easily enough in 2 simple steps:

1. Rename UIRect.Update() to UIRect.CustomUpdate().

2. Add this function to UIPanel:

1.         void Update ()
2.         {
3.                 for (int i = 0, imax = widgets.Count; i < imax; ++i)
4.                         if (widgets[i].panel == this) widgets[i].CustomUpdate();
5.         }

P.S. As for ETC1 stuff... that will never happen. Android is just one platform. NGUI needs to work on all of them.

[r.pedra]

The fact that having every script have its own Update() function vs having a single Update() in a manager that calls child updates has been like that since Unity's inception. It wasn't a secret, there just wasn't a blog post about it. It's the same about all functions. There is overhead every time C++ to C# boundary is crossed. Once you're in C#, it's faster to stay there if at all possible.

I tried it before but realistically there was little noticeable difference in performance and there were odd side-effects related to going from play mode to edit mode that were fixed by using Update() in widgets. Also note that if things are not visible you should keep their game objects disabled anyway, implying their Update() won't run.

If you want to go with the reduced Update() just to try it out, you can try it yourself easily enough in 2 simple steps:

1. Rename UIRect.Update() to UIRect.CustomUpdate().

2. Add this function to UIPanel:

1.         void Update ()
2.         {
3.                 for (int i = 0, imax = widgets.Count; i < imax; ++i)
4.                         if (widgets[i].panel == this) widgets[i].CustomUpdate();
5.         }

P.S. As for ETC1 stuff... that will never happen. Android is just one platform. NGUI needs to work on all of them.

Great answer, thank you for your time. The fact is that we have very very very long lists and that we have to make optimizations by Disabling all the widgets that are not in the range of the clipping panel. Maybe that would have helped us, but we will continue this way.

For ETC1 you could have make it available only for Android, but I understand that you don't wan't to waste time just for it. We will stay with our custom solution.