Performance advice with newest releases

[mdeletrain]

Hi,

We are working with NGUI on a game that needs to handle a big scrolling list of widgets.
Each cell of this list contains approximately 5 sprites and 5 labels of dynamic font.
The list may contain up to 150 cells.
We are using NGUI above 3.0.7 and our goal is to achieve steady 60 FPS on a iPhone 4.

We easily know which cell is on screen so we are culling the cells manually with enable/disable when cells enter/leave screen.

Prior to the “one widget list per panel” commits (0e1c815 and 7b0e78e) we had 2 panels, one for the background, and one scrolling with the list.
We had a total of 5 draw calls, about 130 on-screen widgets.
When not scrolling we were at 60 FPS, but, due to the fact that, at this time, when a widget/panel was enabled/disabled, all panels recompute all drawcalls, we had huge drops when cells were entering/leaving the screen (approximately 100ms frame).

After those two commits (starting from 3.0.8b1, we are using a439f2a), we tried to go one panel per widget, going to 25 Draw calls but our framerate dropped to 10 FPS.
Even worth, when we draw our scene with two panels like before (5 draw calls), we only have 18 FPS when not scrolling
We also noticed some mesh rebuild bug where draw calls were not correctly ordered when cells entered the screen until a mRebuild=true  occurs

Our guess is that the best solution would be to regroup cells in panel of 6-7 cells. then enable/disable those groups. For this, we need the “One widget list per panel” optimization, but the current implementation won’t allow us to reach 60 FPS

So how would you suggest to do this ? Should we wait for some optimizations or change the way we handle the list ? Do you think there may be a performance regression ?

Thx.

[ArenMook]

1. Use one panel for everything. No need for multiple panels. And certainly not one widget per panel. You're killing your performance.
2. Don't enable/disable things. If things go off-screen, let it. Scroll views were designed to be moved efficiently.
3. And don't use culling setting on the scroll view panel either.
4. Check the 'widgets are static' checkbox if they don't move.

[Nicki]

If the list is very long, it may be advantageous to use Containers, such that you have a certain number of active containers in the list at a given point and you fill those with the content that needs to be there depending on where you are in the scroll list.

This will increase performance quite a bit, but will have to be all custom made by you.

[pahe]

2. Don't enable/disable things. If things go off-screen, let it. Scroll views were designed to be moved efficiently.
3. And don't use culling setting on the scroll view panel either.

Could you please explain that a bit further? I would have thought that culling would improve the performance (as there will be less to draw). We also have a scroll view where we enable/disable items or use the culling feature of the panels to improve the performance.

[ArenMook]

Culling on panels does not improve performance. It forces the panel to re-evaluate what's visible every singe update, and then re-create draw buffers, which is very slow. It's better to leave it off so that the panel does not do any evaluation, and the draw buffers don't change as you drag the content around.

This is why it's off by default, by the way.

The only time I advise using culling is if you have too much content inside the scroll view to fit into a single draw call (> 64k vertices).

Enabling/disabling things also forces draw buffers to be cre-created, which is again -- very slow.

So avoid both. NGUI was optimized to be efficient with the default parameters.

[mishaps]

Enabling/disabling things also forces draw buffers to be cre-created, which is again -- very slow.

If I want to hide a widget would setting it's alpha to zero be better performance-wise than enabling/disabling?

[ArenMook]

It still involves re-creating the buffer. In 3.0.8 this whole process is much faster, but in 3.0.7 enabling/disabling can have a quite negative hit on performance and alpha change may be better. So to sum it up... in 3.0.7 -- maybe. In 3.0.8 -- no.

[mishaps]

great. thx for the info.