Severe performance hit on iPad 1 when using scroll list with many items

[01001100]

Hi, Aren!

I've stumbled upon a crippling issue for our project: you see, we need several scrolling lists with ~100-200 items in them... Even in case of very simple items everything works fine on iPad 1 (~60 FPS) only until user starts dragging the list contents, which causes an insane frame rate drop (~11-12 FPS)

Profiler shows that the culprit is UIPanel's LateUpdate() method and if I understand the logic correctly, this makes sense, because during the dragging operation all GameObjects' positions are being recalculated...

Aren, can you please think of some way to fix this problem? It would be great, if all the list items were parented by a GameObject, and only this GameObject's position would be calculated during the dragging operation. From what I understand, the only reason to change scroll list items sizes during non-editor mode is related to animation or corresponding tweens, however I presume it might be better to call the recalculation method manually in such cases... What do you think?

I will send you an exported package, which you would be able to incorporate into an empty project with imported NGUI in it, by e-mail, since there are some scripts from the full version in it...

[Nicki]

I have the same issue, and didn't see an easy fix to it. I'm hoping for NGUI magic from Aren.

[ArenMook]

This is why UIDraggablePanel was implemented. Use it for dragging and all buffers will be reused rather than re-created, resulting in the same performance while dragging the panel as having it stand still.

[Nicki]

I'm actually using UIDraggablePanel and I'm still getting a performance hit. :/

[ArenMook]

From the tech perspective, there is no reason for it. I suggest putting Debug.Log statements into UIPanel.UpdateDrawcalls() or UIPanel.Fill() functions to see if it's getting called when you're dragging the panel. UIPanel.MarkMaterialAsChanged() is another useful function to check to see what's happening. All in all, something should only be changing when widgets come into view / leave the view as you're dragging the scroll list, but that's it.

[Nicki]

I'm gonna do a thorough debug round when I have time in the schedule for it. (So many other things to do first, busy busy).

[littlemuggo]

Had this same issue when creating own system. It is due to the elements still tracking positions, wanting to draw, etc - while off screen. Not sure if it is the same case for NGUI... The objects should be completely disabled if off screen (no movement, attempts to draw, etc). We were dealing with list of 20+ with multiple icons (high and low res), etc and frame rate started to suffer.

[01001100]

Aren, I'm most definitely using UIDraggablePanel!

I suggest putting Debug.Log statements into UIPanel.UpdateDrawcalls() or UIPanel.Fill() functions to see if it's getting called when you're dragging the panel.

I'm sorry, but I don't understand... The UpdateDrawcalls() method is being called constantly even when there is no dragging, because it is being called from the LateUpdate() method... The buffers may be reused, however all GameObjects' positions are being recalculated (if scroll list item consists of 5 GameObjects, that's 200 x 5 = 1000! GameObjects processed during every update caused by dragging......).

[ArenMook]

The updates happen, yes, but they happen regardless of whether the panel is being dragged or not. You say you only get the framerate drop when the list is being dragged, so the logical thing to do is to look into what's causing that by adding some log statement to see how frequently things get called and why. The performance of the dragged panel should be mostly identical whether it's dragged or not.

[Nicki]

The performance is certainly not identical when scrolling and when not. I've take a few screenshots of me running the profiler in the editor to back up my otherwise outrageous claim

Not scrolling


Scrolling:


Looking a little deeper in scrolling:


Looks like UpdateTransforms is the heaviest in my stuff.

[ArenMook]

Deep profile is generally not a good indicator of such things as it adds a fair bit of padding on its own.

That said, it's highly odd that UpdateTransforms is taking up half of the late update's time. All it does inside is checks the widget's local position / rotation / scale to see if they've changed. It shouldn't be getting into the "if transforms changed" loop after that at all (which is where the majority of the time would be spent if it was).

[Revva]

Hi Aren,

I also tried with the UIDraggablePanel example from the NGUI . I use the same scene and loaded around 200 cells. The performance on iPad 1 is hit very badly after some time you cannot drag only. iPad 2 and iPhone 4 and iPhone 4S is having better performance .

Is there any way we can resolve this problem.

[ArenMook]

As I recall I made some improvements in the local copy so you should see a bit better performance with the next update, but aside from that my suggestion is to just reduce the number of items you have in there.

[Nicki]

Would it help to make an "optimizer" that disables the gameobjects when they are moved outside of clipping? Can the UIPanel (or something) detect if it would be clipped/outside the clip area, if it's disabled?

I suppose you could locally on the item save its size, and calculate it, but that in itself might be costly.