It might be something that triggers when the momentum runs, which is only when you've released, but it isn't still yet. Internally on my team, we've made a cyclical wrapper for scroll lists and it increases performance quite a bit and also has the added bonus of having infinite elements in the list.
This is not something we're ready to release yet though, if we ever will be. If we get to a point where the higherups have no objections to it and we feel comfortable putting it out there, we'll post it in here or something.
If the widget in the middle of the draw process gets removed or inserted, this causes the whole list to require re-batching, which is a slow process. Reason for that is this: if you had 3 widgets, one using atlas A, another using atlas B, and last one using atlas A, disabling the 2nd widget will allow the first and last widget to get batched into a single draw call.
I've done a solid optimization pass on 3.0.6 that greatly reduced memory allocations (and thus GC collection spikes).
A cheap way to get around the list rebuilding would be to ensure that there is already a widget active using the same atlas and within the same draw call.
This is resulting in spikes for us too, 7-10 ms in a iPhone 5.
We don't see any way of not firing a mRebuild when enabling/disabling components. How are we supposed to hide/unhide components without triggering a full rebuild? I think that panels should be independent, a widget in a panel which has a different depth than other panel should not fire a full rebuild. Panels not being able to share their depth seems the right thing to me.
We are still looking for a solution. Bluescrn, would it be asking too much sharing your code modification?
Thanks
There is no need to convince me, you already have. I already said I'll change it soon. It won't be back to 2.7 days, but I will make it so that widget changes only affect their own panel. :)