Author Topic: Long length UILabel memory usage  (Read 7327 times)

joahjang

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 4
    • View Profile
Long length UILabel memory usage
« on: February 04, 2014, 02:35:18 AM »
Hi Guys,

I have a really long user agreement context, about 6.5KB as a text file, via UILabel which must be shown before game start.
But I found it consumes too much memory, over 150MB. In Profiler window I can see that memory size of "Not Saved - Mesh" is 20 times larger than without that UILabel.
The UILabel is using Bitmap font and written in Korean.
How can I reduce memory usage or any suggestions?

Thanks.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Long length UILabel memory usage
« Reply #1 on: February 04, 2014, 03:10:08 AM »
150 MB? That seems a tad high.

Each character requires 4 vertices to draw. Each vertex is Vector3 position, Vector2 texture coordinates, Color32 color by default -- 3*4+2*4+4 = 12+8+4 = 24 bytes per character. If you use a shadow effect, that number is effectively doubled. If you use outline -- multiply it by 5. So assuming no shadow effect, 150 MB mesh would imply over 6 million vertices... and the maximum number of vertices per mesh is 65k. In other words, I see no mathematical reason why a mesh would be greater than 65534 * 24 = 1.57 megabytes.

That's how much memory should actually be used. What Unity does under the hood with those meshes once NGUI feeds the vertices in, is unknown. Can you post some pics of what you're observing and any further details?

nerophon

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 7
    • View Profile
Re: Long length UILabel memory usage
« Reply #2 on: February 21, 2014, 09:17:57 AM »
Hi,

We're also experiencing memory crashes on mobile due to using extremely long UILabels (for Ts&Cs, Privacy Policy, FAQ, etc.).
Profiling, we find the memory leak is in the Not Saved - Mesh category as noted above. I call it a leak because we have found no way to clear this memory once it increases, even after the user navigates away from the screen and we:
Destroy ( view ); delay 1 frame; Resources.UnloadUnusedAssets (); GC.Collect ();

I tried adding UIDrawCall.ClearAll () and UIDrawCall.ReleaseAll (), but those don't appear to release the memory either. Rather they appear to make the situation slightly worse.

So our primary questions are: how do we release this memory? How to we kill the meshes?
Our secondary question is: does a long UILabel really have to cause a 35MB mesh memory spike?

Additional notes: looking at the profiler, we actually see several entries under the mesh category, but apparently using the same texture and font. Each entry is taking its own memory, and contributing towards the category total. Individuals entries range in size from 300k to 6Mb at peak. Most go up together, but some sit lower for awhile as others rise. None of the entries ever goes down in size or gets removed.

To repro this, just put a few UILabels in a scrollview, then dynamically fill the text in via code at runtime. They text should be very long, say about 20 mobile screens worth. Split that amount across the labels if using a single label fails to display or causes a crash. We test with iPod touches since their memory characteristics are relatively weak. Get device and editor on same Wifi and autoconnect profiler to see (hopefully) what we see in the profiler. Profiler in-editor produces strange results and we question their accuracy / relevance.

Many thanks, let us know if you would like further details.

Nicholas Bellerophon
Senior Developer
Yummi Media

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile