Messages

1

NGUI 3 Support / Re: GC Alloc each frame

« on: March 05, 2014, 09:31:40 AM »

Im currently not using ScrollViews and dont think I have need to. You think its ok to keep it like this for now? The GC allocations were dropping our game from 60-30 and this has resolved it. In between scenes I will most likely Trim the buffers manually to stop them getting too large. As for now though it seems pretty steady at 128 allocations.

2

NGUI 3 Support / Re: GC Alloc each frame

« on: March 05, 2014, 08:26:38 AM »

This seems to solve all problems with GC allocations. Now the buffer only needs to grow to accommodate new items thus reducing the need to re-alloc when an items is enabled/disabled. Simply hiding a sprite for a few frames caused Trim to re-allocate and when it became visible caused it to re-allocate a higher amount.

This way it constantly has the max size it needs. Ive monitored the memory usage and it stays constant without any GC allocations.

3

NGUI 3 Support / Re: GC Alloc each frame

« on: March 04, 2014, 10:31:18 AM »

Hey Aren

After some hacking and twiddling ive come up with a solution to this. No idea if its perfect or what it'll break internally. In BetterList the trim methods were getting called when the list size shrunk which caused a re-alloc everytime.

I removed this call to make it retain the max memory it has allocated thus no re-allocation is needed. I also increased the initial allocation on better list to 64 and the max check now clamps to 128. Might be overkill.

Like I say I dont know if this trimming causes issue elsewhere but this has completely removed and GC allocations NGUI was causing in re-building.

Here is what I changed inside BetterList:

1.         void AllocateMore ()
2.         {
3.                 T[] newList = (buffer != null) ? new T[Mathf.Max(buffer.Length << 1, 128)] : new T[64];
4.                 if (buffer != null && size > 0) buffer.CopyTo(newList, 0);
5.                 buffer = newList;
6.         }
7.  
8.         /// <summary>
9.         /// Trim the unnecessary memory, resizing the buffer to be of 'Length' size.
10.         /// Call this function only if you are sure that the buffer won't need to resize anytime soon.
11.         /// </summary>
12.  
13.         void Trim ()
14.         {
15.         //if (size > 0)
16.         //{
17.         //    //if (size < buffer.Length)
18.         //    //{
19.         //    //    T[] newList = new T[size];
20.         //    //    for (int i = 0; i < size; ++i) newList[i] = buffer[i];
21.         //    //    buffer = newList;
22.         //    //}
23.         //}
24.         //else buffer = null;
25.         }

4

NGUI 3 Support / Re: GC Alloc each frame

« on: March 04, 2014, 06:51:56 AM »

Latest Pro version has per-draw call buffers, so this should address the allocation issues.

Hey Aren, im still get GC alloc triggers in late update. Although less frequently now. Just on a panel that animates a FilledSprite.

5

NGUI 3 Support / Re: Massive GC Spikes ('batting' UIPanels)

« on: March 04, 2014, 02:16:55 AM »

Thank you so much for the quick resolution. The games much more stable now.

6

NGUI 3 Support / Re: Massive GC Spikes ('batting' UIPanels)

« on: March 03, 2014, 04:48:23 AM »

Seems we both have the same issue here. Although removing the static fields only spread out the alloc's for me. Still better than every few frames I suppose.

If you only need to move something I found its less stressful to move a panel with 1 object. It doesn't solve issues of scaling and animating though,

7

NGUI 3 Support / Re: GC Alloc each frame

« on: March 03, 2014, 04:34:36 AM »

Thanks. In this case it was NGUITools.SetActive which was causing the alloc. The GetComponents inside that function was triggering it.

Setting the transform was also causing an alloc too. I removed the sprite transform set to a panel transform set and this issue is no longer present.

I am however having the same issue as doggan. With a filled sprite needing an update each frame is causing a re-draw which inturn causes a GC alloc to throw.

8

NGUI 3 Support / Re: GC Alloc each frame

« on: March 03, 2014, 03:10:14 AM »

Theres definitely an issue here. Ive moved the culprit into its own panel so it should be a draw call of one Sprite. Same thing happens (see attached)

Here is the code I use to update that Sprite:

1. private void UpdateExitSymbol()
2.     {
3.         if (Vector3.Distance(Blaze.transform.position, new Vector3(512, 0, -512)) > 20f)
4.         {
5.             Vector3 screenPos = Camera.main.WorldToScreenPoint(new Vector3(512, 8, -512));
6.             float fBounds = 17.5f;
7.  
8.             // Move the sprite in screen space
9.             screenPos.x = Mathf.Clamp(screenPos.x, fBounds, Screen.width - fBounds);
10.             screenPos.y = Mathf.Clamp(screenPos.y, fBounds, Screen.height - fBounds);
11.  
12.             Vector2 worldPos = Level.Instance.GetUICamera().ScreenToWorldPoint(screenPos);
13.             FireExitSymbol.transform.position = worldPos;
14.  
15.             NGUITools.SetActive(FireExitSymbol.gameObject, true);
16.         }
17.         else
18.         {
19.             NGUITools.SetActive(FireExitSymbol.gameObject, false);
20.         }
21.     }

The GC alloc happens constantly when the active state changes and only frequently when I move the Sprite. Is this a bug or am I doing something seriously wrong here?

9

NGUI 3 Support / Re: GC Alloc each frame

« on: February 28, 2014, 05:41:35 AM »

I identified the issue was with enabling/disabling a sprite. I tried just fading the alpha to see if that would stop a re-draw but no luck.

What are the common things that cause a re-draw? I need 3 or so icons to appear at specific events:

Notification icon when near an interactable object
Exit indicator (displayed when over X distance away from exit)
Damage indicator (displayed when taking damage)

These are world space sprites so they do require me moving their position a lot too. Is it the position change causing the redraw or the enabling?

10

NGUI 3 Support / Re: GC Alloc each frame

« on: February 28, 2014, 04:27:10 AM »

Hi, my reg email arrived so i'll continue this.

This still happens when profiling on Vita.

The deep profile (on PC) shows its reallocating for the mesh which is linked to my UI panel. Im not adding anything to this panel. All im doing is moving the fill amounts for 2 sprites and enabling/disabling something floating GUI over the player to show hes in danger.

See attachments for the profiler