Huge mesh sizes

[dillrye]

Hello.  We have just upgraded from NGUI 2.7 to 3.5.  Most of our app is almost entirely GUI driven and most of our scenes are entirely rendered by NGUI(No custom meshes).  We noticed a massive slowdown in our application when deployed to phones and did a little bit of research.  A scene that we have not changed except for upgrading to NGUI 3.5 now takes up an extra 200+ megs of memory.  Looking at the profiler and doing a before/after comparison, it looks like NGUI 3.5 is generating a massive amount of mesh data.

Ngui 2.7: 2mb of mesh data
Ngui 3.5 210mb of mesh data.

I wanted to add that we do use sliced sprites, but we do not use any tiled sprites in our app.  We do use a fair amount of text also, but both scenes (2.7 and 3.5 versions) are using the same sprites/data.

[ArenMook]

I don't see why there would be so much memory used, but try calling UIDrawCall.ReleaseInactive to release inactive draw calls.

[dillrye]

I'm noticing all mesh sizes are 3.8 to 3.9 megs.  Is it possible full arrays are being allocated?

I wanted to add that i just tried UIDrawCall.ReleaseInactive();, but it didnt change anything.  All meshes related to NGUI are still at 3.8 megs (on a mobile device, specifically android at the moment).

[ArenMook]

It's possible. One of the optimizations in UIDrawCall makes it use the full buffer rather than the trimmed version of it as trimming a buffer means garbage collection allocation. Put a Debug.Log inside UIDrawCall around line 432 to see how big of a buffer is being set.

Doing some math it doesn't quite add up though. Maximum possible mesh size is 65,535 vertices, 12 bytes for position, 8 for texture coordinates, 4 for color, that's 1.6 megabytes. Even with maximum number of indices (65k * 1.5 = 98.3k), at 4 bytes each, that's 393 kb, so absolute total would be under 2 megs for the lagest possible mesh.

[ArenMook]

I did a quick test locally. You can safely reduce the size of meshes by adding this line below line 405 in UIDrawCall:

1.                                 // If the number of vertices in the buffer is less than half of the full buffer, trim it
2.                                 if (!trim && (verts.size << 1) < verts.buffer.Length) trim = true;

It should go right below

1.                                 // Non-automatic render queues rely on Z position, so it's a good idea to trim everything
2.                                 if (!trim && panel.renderQueue != UIPanel.RenderQueue.Automatic)
3.                                         trim = (mMesh == null || mMesh.vertexCount != verts.buffer.Length);

[dillrye]

ok, so it looks like the vert buffers are being set to: 32768 which I am thinking is super high for the amount of polygons i have on the screen. The UI isnt super simple, but its definitely not 5000+ quads worth.  I also noticed that this seems to progressively climb, the allocations are going in order:

32
128
512
1024,
2048
32768

[dillrye]

Looks like that did it! I'm back down to using a LOT less mesh memory, about 6 megs total.  It looks like there is 5 megs worth of mesh data still associated with one of my atlases.  Specifically one we use for  a couple of simple nine patches(sliced sprites).

[ArenMook]

Ok, perfect, thanks for checking. I will have this fix in the next update.

[oddurmagg]

Is this in yet ?

[dillrye]

As of 3.5.1