Weird performance drop on UIPanels

[hjKNG]

We've been working on a game project for a while now, which is about to be wrapped up. However, we are now running into a strange problem that seems to be NGUI-related. Let me first explain the setup.

Our game uses several different NGUI objects (meaning seperate UIRoot components) in different places of the game. We have our main game GUI which is one NGUI object, then there's our in-game menu which is another and an effects object for fading to/from black, showing load screens, etc. When we came around to creating the credits for our game, these were also created in a separate NGUI object that we instantiated when needed. This all worked well for a long period of time (and still does), but at some point we noticed that after showing the credits of our game, we experienced a very drastic increase in computation time for UIPanels.

I started trying to narrow it down by using the Profiler.BeginSample method and eventually figured out that it was calling the method FillDrawCall that seemed to be taking a huge hit. There was no more calls to this method than before the slow down, but suddenly it took like 10-20 ms longer pr. call to this function. At the same time, the Profiler also reported the camera using a lot of time each frame on a process named "Mesh.CreateVBO".

I've tried to find information on this behaviour and found others that had reported something similar on this board, but not with a solution that works for us. The strange thing is that this frame rate drop does not happen when using any of or other NGUI objects. No matter how much we go back and forth between levels, in-game menu and main menu, there never seem to be any performance problems. It only happens after we've shown the credits, which are basically nothing but a panel containing several labels that fade in and out. What's even weirder is that the performance issue doesn't happen if we only show part of our credits (like for instance only the first five labels), so it doesn't seem to be actually instantiating the object that's causing it. I also tried integrating the credits as a part of our 'effects UI', since this one is pretty much always active in the game, but the problem is exactly the same.

I know it might sound very confusing, but generally, I'd just like to know what could cause the dramatic increase in calling FillDrawCall, or get some hints and inputs on where to start looking for the error. I feel like I've tried a lot of stuff to find out why this is happening and how to fix it, but as said, it only seems to happen after having shown some amount of credits. The credits objects are deleted after use and there are no other objects leaking. Any help would be much appreciated.

[ArenMook]

First thing's first. What's an "NGUI object"?

In a typical UI set up with NGUI, you would have 1 UIRoot, and many panels underneath it. Each panel would be a separate game window. Animating panels is cheap and doesn't involve re-creating draw calls. Animating groups of widgets on the other hand... is expensive. You mentioned fading in labels -- this would fall under the "expensive" category, especially if you use effects like shadow or outline.

[hjKNG]

Sorry for the vague description. I will try to flesh out the setup a bit more. Basically, when the game start it reaches the main menu, which is a separate scene which is made almost solely with NGUI. When I say "NGUI object", I'm referring to an UIRoot object with a child UICamera and then several panels as children of the camera. When you then load a level in our game, we first instantiate our EffectsUI, which again is an UIRoot object with camera and panels, but since we want it to exist across level load, it is separate from the main menu UIRoot object. Once the gameplay level has been loaded we activate a new UIRoot object, which is our game's graphical interface.

I know this is not exactly how NGUI is probably designed to be used, but it would also get clunky and weird - at least in my opinion - to have both the main menu, load effects and in-game GUI in the same UIRoot. Since it had never caused problems earlier in the development process, I figured it wouldn't be a problem.

Now, when creating the credits, it was originally also done in a separate UIRoot object that we instantiated in the scenes where we needed it (there are two scenes in the game where this can happen), which does also work properly, but as said, after having run the credits, it causes this slow down when returning to the main menu. The credits' UIRoot object is deleted when loading the main menu, so it doesn't exist any more, once we get back to the main menu. At that point, it is once again only the main menu's UIRoot object that's active.

We do animate groups of widgets, which I know is expensive, but it is not a problem at any other point in our game. As said, no matter how much other stuff we load and various NGUI objects get displayed, this slow down doesn't happen. It only happens after the credits has been displayed. We don't use any effects on the labels that we fade in and out and there doesn't seem to be any impact on performance while the credits are running either. It's only after we return to the main menu that the issue is apparent.

As I also described in my previous post, I tried to merge the credits into our EffectsUI object that we use when fading and loading, such that we could avoid creating an extra UIRoot object just for the credits, but the problem is exactly the same. We could of course try to make sure not to animate any groups of widgets anywhere, but it just puzzles me that there is no problems at any other place in the game with these animations, except for after having shown the labels of our credits.

Again, I know it's probably a bit confusing and a very complex situation, where the source of the problem could be in a lot of places. That was why I just wanted to know what could cause this issue with the expensive call to FillDrawCall.

[ArenMook]

it would also get clunky and weird - at least in my opinion - to have both the main menu, load effects and in-game GUI in the same UIRoot.

Why? I always stick to only 1 UIRoot+UICamera, and many panels underneath it. Simple rule of thumb is 1 window = 1 panel. Makes it easy to transition between them too. Tween one in, tween the other one out. Starlink's UIWindow framework makes transitioning between them a single line of code, and I use the same system in Windward. One root, many windows -- all of them start disabled, except for the loading screen.