Tasharen Entertainment Forum
Support => NGUI 3 Support => Topic started by: xecuter on June 12, 2014, 06:01:10 AM
-
Hi,
I have some problems with Allocation.
Everytime I tween something my GC Alloc goes as high as 250KB (on UIPanel.LateUpdate())
I have alot of gui-elements with various tween effect. (clock ticking, menu "side-scrolling" transsisions, Ping-pong scale effect on some sprites etc.)
Why is this happening and how can i prevent it?
would it help to swap out the tweens for animations?
Thanks.
-
anyone? :)
-
Are you seeing this on the profiler on the device or the profile in-editor?
-
When you change something in the UI -- whether it's altering the color of a widget or moving some widget around -- this causes NGUI to re-evaluate the draw call used to actually make that widget appear on the screen. This is a slow process, and if you have 1 widget that's changing, and beside it you have 1000 widgets that don't change, all 1001 will have to be rebuilt because changing one still means having to re-fill the draw buffer filling in the other 1000.
For this reason, when moving things it's best to move panels. Moving panels is basically free as far as performance goes. And when changing things frequently, consider separating them from the other widgets by placing them underneath a separate UIPanel.
-
The alloc is the same, both in standalone and editor.
Ah, thank you...
So basicly all my optimization trying to reduce the draw-call's (only got 2 in my gui) is the thing thats killing me.
Which means that a low number of drawcall's Isn't necessary equivalent to good preformance?
So I need to wrap all my moving objects in panels, and preform the tweens on them, is that correct?
that would result in alot more draw-calls, but I guess I can go alot higher then 3, without any issues.
-
Think of it this way:
A panel generates a 3d model of all the sprites and labels inside of it. A 3d model can't be modified run time - you have to destroy the old one and make a new one if a single little Quad needs to move.
This means for every panel, if anything moves inside of it, the model has to be recreated. The old model becomes garbage, which obviously needs to be GCed at some point.
If you wrap every single widget in a UIpanel, then you would essentially re-create the old GUITexture / GUIText system where it did just that. Every panel costs a single draw call , so to make things faster since draw calls are (relatively) expensive, we batch things together to the aforementioned 3d models.
The optimal way to do it is with these guidelines:
- Put everything that updates rarely or never in an overarching UIPanel
- Put things that need to change often( more than rarely), into their own panels (slide ins, notifications, scores).
- Where possible, animate the UIPanel instead of the widgets as this just means moving the 3dmodel which is cheap.
On mobile you can run 100 draw calls without breaking a sweat (on newer devices).
-
Thank you for the detailed answer Nicki,
But, I'm having some problems with this in practice.
I'ts still allocating when I move the panels. (smaller amounts, 2-100kb depending on the size of the panel).
I've tried both using tweens and animations.
What could i be missing here?
(it also allocates ~150kb/frame when i scroll in a scrollview)
-
Try the Scroll View example that comes with NGUI. There is no allocation happening while the scroll view is being scrolled, aside from 3.3 kb from Physics.Raycast which you can't avoid until Unity's new no-allocation APIs are live.
-
Uhm.. I just updated Ngui, and that seems to have completely solved the issue...
but, it also removed allocation on some of the "non panel" tweens.
should I continue putting stuff in panels? or only when it allocates?
-
All my suggestions were for the current latest version of NGUI. What version were you on before? In the future please always update first.