NGUI Performance questions

[ENAY]

Simon129, can you explain to me that works?

So you only have enough items to fill the window and as you drag, you simply scroll all the contents of the viewable by 1?
The shift and unshift part, you move the outside of the drag area?
eg I have items scrolling in the X direction, so I should move all the items outside of the area each side by say about 500 (or a huge number) in the Y direction and then just put them to 0 in the Y direction when they are viewable inside the panel?

Not quite sure I understand your explanation. Sorry about that

By the way, instantiate is very slow isn't it. What I have been doing is creating 100 items, and then just deleting the objects I don't need. Deleting items is incredibly fast and it seems better doing that than instantiating at all.

[simon129]

Simon129, can you explain to me that works?

I upload a picture, and hope you can understand what I mean.

[amaranth]

@simon

How do you get your objects to align properly when you reposition them? I've managed to get a menu slot that scrolls out of view move to the end of my list, but the positioning is never quite right. If the player drags slowly, the slot goes into the correct position, but if the player drags quickly, it appears far down the list. Maybe UIGrid refresh is what I need? Not sure.

[nah0y]

You're using the same technique that is used in Android for ListView I think, really nice

Would love to see that by default in NGUI ^^

[Pyro]

Hi,

I am also having performance issues with draggable panels. I have a scroll setup in the same way as in the example. It runs fine even with +1000 items. I use 2 different atlas, an so I get 2 drawcalls. However, things go really bad when I have a UITexture as part of the items. My drawcalls go from 12 to +200, and framerate gets really sluggish. Do you guys know if that's expected when using UITexture in a draggable panel? Do you have any solution?

UITexture is really importante in this case, cause I have those items coming from a database.

Thanks in advance.

[ArenMook]

UITexture draws a texture as a separate draw call. It won't be batched because it can't be batched. Only atlas-using widgets can be batched.

Solution is simple: don't use the UITexture. It's meant to be used only for things like large backgrounds that shouldn't be atlased.

[Pyro]

So, just to clarify, the solution you suggested requires that I build the atlases on real time, just before populating the panel. Correct? Do you see any other possible solutions?

Thanks again.

[Nicki]

If you do something similar to what Simon suggest above, you can use UITexture just fine.

Each UITexture adds one extra draw call, by keeping the number of UITedxtures down, you keep the number of draw calls down. You just have to be clever about it - it's totally doable.

[akbiggs]

We ran into the UIDragPanel slowdown issue in our game project with 30 or more items in the list.

Simon's solution sounds effective and easy to adopt into many lists at once by abstracting the "pooling" logic into a Monobehaviour. However, if you can't get it to work, we tried an alternative approach which might work well enough for your purposes.

We attached a box collider and a kinematic rigidbody to a game object which would essentially act as the "render window" of the drag panel, as well as to each of the list elements of the drag panel. This let us hook into the "OnTriggerEnter" and "OnTriggerExit" events in a script attached to the render window. We would use these events to toggle the active state of the drag panel children to true or false depending on whether or not they were visible. To prevent some "popping" from occurring as the objects move in and out of view, we made the collider on the render window larger than the area that was actually visible to the player.

The box collider and rigidbody for the child elements will need to be on parent objects to the actual contents of the elements, which are what you actually set to be inactive. If you set the parent object to be inactive or put the collider on the same object as the contents, the collider would also get disabled when the object is out of view, preventing the element from reappearing when it should be in view. Also, the children should be disabled by default, since otherwise they will only be set inactive when they leave the render window, making the list sluggish until the user drags to the bottom.

It seems to work smoothly in the Unity editor, although we're experiencing some lag with it on the iPad (admittedly in a scene filled with other crud that's slowing the game down a bit already), probably due to the overhead of having rigidbodies on so many objects. One option we're considering to work around this is to use a normal drag panel on smaller lists and then switch to the box collider method when the list becomes sufficiently large.

Sorry for the wall of text -- hopefully this is helpful to anyone running into this issue.

[PoN]

I upload a picture, and hope you can understand what I mean.

Could you tell , how do you check(algorithm) of visible/invisible obj in clip panel(draggable panel) ?

[ArenMook]

2.6.3 actually has performance improvements that also affect draggable panels. Only for Unity 4.1 or higher, however.

[LouAdrien]

Thanks ArenMook for your answers, I have a little question though regarding how to set panel to static, should I use the widgetsAreStatic member or am I missing something? Also is a panel the smallest unit that can be set to static? Like for exemple something to do on UIDragPanelContent?

My second question concerns the same one as Pyro asked : you were suggesting the best way is to always use atlases, but in real-life situation we often get content which are not included in the original build and therefor not incorporated in atlas via the editor, do you suggest that we build atlas at runtime and then use it to create the panel content? If yes would you have any references to exemple of generating atlases at runtime, especialy used in conjunction with a draggable panel?

Thanks in advance for your help

[ArenMook]

1. If your widgets within the panel will never move, scale or rotate, yes set the widgetsAreStatic flag to true to improve performance.

2. Depends on whether you need to limit your draw calls. If you're on a mobile device, then yes, adding dynamically downloaded images to an atlas or a sprite sheet would help. The Atlas Maker class generates everything using code, you could just lift code from there. Just omit the part that saves the texture and prefab to disk.