Messages

1

NGUI 3 Support / Atlas leaking when loaded from scene in asset bundles?

« on: February 26, 2015, 08:55:52 AM »

Hello,
Using memory profiler, attached to standalone Windows player, we see our main Atlas texture leaking every time we switch scenes. I have a feeling, the way we use them with asset bundles is the cause, but not sure.

The scenario is not that usual:
For the UI, we have 3 asset bundles containing several scenes with NGUI stuff in them - one bundle for each main state of the game - Login, Garage, Battle.
When game state changes, we load new 3D world using Application.LoadLevel, which cleans old gameobjects(UI stuff too) and does implicitly Resources.UnloadUnusedAssets. Then we load the UI scenes from the corresponding bundle, using LoadLevelAdditive, then we unload the bundle.

So you can imagine, the main atlas that is leaking, is present in each of these bundles (we are building them using BuildPipeline.PushAssetDependencies)

We already fixed couple of places that hold static references to NGui stuff, which we found using the profiler, but the atlas is still leaking - new instance appearing after each switch of game state.

For the leaked atlas texture, profiler now shows just 2 items in (Referenced By:) section:
UIAtlas
ManagedStaticReference

Drilling down these items shows nothing.

I managed to clean these leaked instances crudely by doing this after scene switch:

1.                 foreach(var atlas in Resources.FindObjectsOfTypeAll<UIAtlas>())
2.                         {
3.                                 Texture tex = atlas.texture;
4.                                 GameObject.Destroy(atlas.spriteMaterial);
5.                                 GameObject.Destroy(atlas);
6.                                 GameObject.Destroy(tex);
7.                         }

Any idea what could be causing this?

Thanks!

2

NGUI 3 Support / Re: Anchoring bug with UIPanel, after switching resolution, outside editor

« on: June 13, 2014, 03:36:28 AM »

So, is it a confirmed issue?

3

NGUI 3 Support / Re: Anchoring bug with UIPanel, after switching resolution, outside editor

« on: June 11, 2014, 02:13:25 PM »

Sent an email to support at tasharen.com some days ago. Is that what you meant?
Thanks

4

NGUI 3 Support / Re: Anchoring bug with UIPanel, after switching resolution, outside editor

« on: June 07, 2014, 05:37:55 AM »

Just tested it on 3.6.3 and it does not seem fixed.

5

NGUI 3 Support / Anchoring bug with UIPanel, after switching resolution, outside editor

« on: June 06, 2014, 05:15:04 PM »

Hello,
It seems we have found a very basal bug with anchored UIPanel, containing widgets anchored(OnEnable) to it. It only happens in standalone builds, not inside the editor!
The scenario is this:
Have a UIPanel, with clipping either 'Soft clip' or 'Constrain but don't clip', anchor it to close to the sides of the UIRoot, with anchor execute mode 'OnEnable'.
Add a sprite within it, big enough, anchor it close to the sides of the panel, with anchor execute mode 'OnEnable'.
Add UIToggle mechanism to activate/deactivate the panel.
Add some mechanism to switch resolution.
Build and start the application.

Toggle activate the panel. Toggle deactivate it.
Switch resolution.
Toggle activate panel. Woala, sprite, and probably panel, do not update rect and stay the same size as in the previous resolution. If you disable and enable second time, sprite resizes correctly. If you switch resoltion while panel is activated, all works fine too.

It also work ok if panel is OnEnable, widget is OnUpdate + panel is OnUpdate, widget is whatever.

NGUI version it 3.5.9

Thanks in advance!

6

NGUI 3 Support / Is it possible to pass static parameter values with the new delegate system?

« on: April 24, 2014, 10:48:38 AM »

Hi,
I am wandering why this is not an option - it will make UI controls interaction even more flexible - out of the box. Is there some hard technical limitation to achieve this?
Thank you

7

NGUI 3 Support / Terrible performance with NGUITools.AddChild or activating populated ScrollView

« on: April 22, 2014, 04:44:14 PM »

Sorry, i meant UICamera.Update (fixed previous message), with a callstack like this:
UICamera.Update
--UIToggle.OnClick
----GameObject.Activate
------UIRect.OnEnable

This is the thing that takes most time when activating a populated scroll view. UIPanel.LateUpdate takes much less time.
In UIRect.OnEnable its seems, widgets get almost entirely re-initialized. What is the advice to keep this overhead to a minimum?

UIPanel.Refresh i don't see a good place to call it, before deactivating some UI hierarchies, because Widgets Start handlers should run first. This calls for some wicked custom script execution order and coroutines - which will not work naturally with UIToggledObjects for example.
So i added a property 'OnNextFrame' to UIToggledObjects script, and skipping the first frame seems more straight forward overall.

8

NGUI 3 Support / Re: Terrible performance with NGUITools.AddChild

« on: April 21, 2014, 05:29:52 PM »

Hi,
So pre-instantiating solves half of the problem.
The other performance problem is activating the scroll view with 30 items in it, especially for the first time.

When pre-instantiating, if we let the items be active for 1 frame, then deactivate, consequent scroll view activation times gets much better:
* UIPanel.LateUpdate takes much less time
* UIRect.Start is not called any more
* UICamera.Update (the button click handler that activates the ScrollView) however starts taking much time to execute (calling UIRect.OnEnable internally), but is still better than UIRect.Start

Is this a normal thing to do to further avoid performance spikes?

As seen in the uploaded sceenshot NGuiActivate.png, UICamera.Update() takes quite some time 45ms, and this is the consequent ScrollView activation, which is actually the better performant.
I understand draw buffer is re-created in UIPanel.LateUpdate, but what happens in UICamera.Update(), and can we avoid it somehow?
P.S. It seems, draw buffer is invalidated and widgets get reattached to the first found parent Panel. Can we manually initiate that when needed, and let it not be automatically done on gameobject activation?

Thank you!

9

NGUI 3 Support / Re: Terrible performance with NGUITools.AddChild

« on: April 17, 2014, 06:51:23 PM »

Thanks for the answer Michael!

So we need to handle these two situations without getting severe performance spikes:
1) Populate grids with lots of items
2) Deactivate/Activate grids with lots of items

For 1) Several solutions may be possible:

- Pre-Instantiation and Pooling of items. When pre-instantiating, should the items be left active 1 frame, so they are 'pre-warmed' (UIRects.Start handlers are called upfront), and activating them later will be cheaper?

- Init Grid with lightweight placeholder items (get them also from pool maybe), and Instantiate/GetFromPool real item, when placeholder gets visible. Is this even possible, how hard will it be to decide that a placeholder needs to show the real item?

- Instantiate items prolonged in time, one by one. Spike will be avoided, but ScrollView will have to rebuild geometry each time a new item is added.  Is this feasible?

For 2) Seems the great spike may be when we activate a heavy UI sub-hierarchy for the first time. So a sound solution would be to pre-activate all heavy UI herarchies at scene load and deactivate them right after - shall that help?

Which of these sound true?
Thanks!

10

NGUI 3 Support / Terrible performance with NGUITools.AddChild

« on: April 17, 2014, 11:22:37 AM »

Hello,
We are currently evaluating NGUI, in order to replace our old UI system. On several locations in the UI, we have scroll views with grids, which can contain dozens of child items - like player inventory items, shop, etc.. These items can be prefabs, made of several labels, progress bars, sprite(s).

When we add 30 of these items, using NGUITools.AddChild, there is almost 200ms spike in the Profiler.
After adding them, when just deactivate/activate the scroll view, the spike is like 50-60ms, which is also not quite acceptable.
It is a powerful Itel I7 PC, the tests are being made on.

These spikes are alike even when attaching the items to an empty scene UIRoot directly - no scroll view/grid at all.

When instantiating a simple prefab with just 1 sprite, the UICamera.Update+UIRect.Start spike is around 15ms. The complex prefab has 7 labels, 1 background sprite, 1 texture, 4 progress  bars in it, and Math proves the problem does not seem to be in the complex prefab.


Am i doing something wrong, and if not, what is the strategy for dealing with such scenarios - paging or lazy instantiate of some sort?
NGUI version 3.5.3 btw.

Thank you!