TMPro and memory allocations

Hi,

One of the use I have for TMPro is a floating score display when points are scored. The text appear over a location and slowly animates up and fade. I’m using the UGUI component in a Canvas. I’m currently in 2018.1.8f1 with TMPro 1.2.4.

So I have a pool of pre-instanciated object that I use to float the score. Once the animation is over, I disable the game object. When I need to show another score, I find an unused object and turn it on with SetActive(true) and set the text on the TMPro.UGUI component.

I didn’t noticed this in the previous versions (I have just upgraded from 5.4.3 to this new unity version) but the profiler is now telling me there are memory allocation associated with my floating score display. Using Deep Profile, I’m finding that I get about 2K during TMP_MeshInfo.ctor (not only on the first activation, sometimes later as well) and a further 0.6K during GraphicRegistry.RegisterGraphicsForCanvas() (more specifically in IndexedSet’1.ctor) every time I activate the game object. I attached a screenshot of the profiler.

So my questions:

  • What triggers the TMP_MeshInfo allocation and how can I mitigate it?
  • Is this the expected behaviour to have memory allocation (RegisterGraphicsForCanvas) on SetActive?
  • If so, what is the proposed best way to handle temporarily showing text objects?

Allocations for the buffers for the geometry should only happen when these buffers need to be increase in size or when their allocations exceeds a delta of 256 characters at which point they are reduced in size to reduce the geometry.

I would need more specific details on your pooling system but it is certainly possible to avoid allocations here other than the initial ones or when the buffers need to grow.

That I am not certain about. There are also allocation that only occur in the editor so make sure you test / profile in a build and not in the editor.

Good point about testing on the device. Same result however: GraphicRegistry.RegisterGraphicsForCanvas() generates 0.5K worth of memory every time the game object with TMPro is turned on (whether from setting .enabled on TMPro or SetActive on the gameobject). It happens independently of whether the text is changed between activation.

I found a workaround of parenting the TMPro label to a CanvasGroup and changing the alpha on it (at 0 it doesn’t generate draw calls for the children). But it feels strange there is so much memory allocation associated with an operation that ought to be pretty lean.

(Case 1063137) TextMeshProUGUI.OnEnable causes GCAlloc always

The behavior is specific to the Canvas system and GraphicRegistery.RegisterGraphicForCanvas(). I’ll update the bug report to have the UI team take a look at this.

1 Like