UIScrollView - Performance with too many widgets

[Dagohan]

I'm using the UIScrollView component with too many item sliding on it (+200). The performance was not compatible for mobile so I have written a dynamic activater/disabler to work with UIScrollView. It activates the visible items and disables the ones that are outside of the clipping region. This method improved performance considerably but there is still some issue with items that have too many widgets on them. I tried to diagnose the root of the problem with profiling. Here are them;

Overall profiling:

The UIPanel.LateUpdate() and the UIScrollView.LateUpdate() are the main bottleneck points in the CPU. The UIScrollView's main calculations were about calculating widget bounds which I think it is for to restrict the items inside the panel. I doubt this can be evaded at all but if there is a fix for this I would really like to try it out. My main concern is with the UIPanel.LateUpdate().

UIPanel.FillAllDrawCalls():

Seems that the UIPanel is updating it's buffer, geometry and material on scroll slide. This seems to be one of the the main performance issue in the UIPanel.Update()

UIPanel.UpdateWidgets():

The other main performance issue on the UIPanel is because of the UIWidget.UpdateGeometry(). It seems as if the sprites on the widgets are getting rebuilded.

As far as I know the widgets do not get calculated if they are not getting translated in the world. In this case they are getting rebuilded but they are not the ones that are moving. The scrollview that is parenting them is moving (which has UIPanel on it) but somehow the widgets under it are getting rebuilded. Is there any way I can increase the scrollview's performance?

[Nicki]

If you have anchors on the internal elements in the scrollview, that might trigger a re-build. Same if you change alpha, color or move any of the individual elements. Activating and deactivating will also rebuild the mesh.

[Dagohan]

I checked all children to make sure they do not have any anchors. There are default button color tweens but I am not triggering them while scrolling yet they still get rebuilded. My script is activate/deactivating them and that is probably triggering a rebuild but when I close that script I still get those rebuilds and it makes the performance unacceptable (with 1000 items, around 4 fps on PC).

The only moving part is the scrollview itself yet the performance is not good enough if the items have a lot of widgets in them. I also tested that UILabel is the most problamatic component of all in scroll view to have. The more text in UILabel just makes it worse (there is no effect on texts and it is not dynamic font). I suspect it is because of when the rebuild triggers all letters in UILabel are recalculated as if they are images, which hits the performance hugely if you have a lot of uilabels (or have a single uilabel with a lot of letters in it).

I will implement a second optimizer script that re-uses items as they go out of the scrollview. It will not activate-decativate but just refill the one that goes out of the bound and put it in the position of the newly coming item.

If you have any ideas about how to avoid panel rebuilds, please feel free to share them.

[ArenMook]

When you activate / deactivate objects, the draw calls have to be rebuilt. The UIScrollView already has an option to automatically cull objects that aren't visible. Or was it UIPanel? I forget and can't check right now as I'm at PAX. Either way though, whenever you enable/disable something, it will cause draw calls to be re-evaluated and rebuilt.