Anyone tested TextMeshPro with large chunks of text?

We have a use case where we will need to render and manipulate large chunks of text like in a document.

Does anyone have any experience with or know how well TextMeshPro handles such scenarios?

Any examples?

Any tips for achieving optimal performance?

Thanks,

-JVR

 

be careful. TMP creates huge amounts of garbage when using long texts.
(20 kB of text: ~3000 words, generates more than 100MB garbage in the frame where the text is assigned)

in our game there is a "about" window, with legal texts and stuff. and this created up to 3GB of garbage.
This is still the case in the latest TMP version.

an excerpt from our findings:

 

Thanks for the extensive info.

I guess all I can say is OUCH!

 

In terms of allocations, these occur because the initial buffer allocations starts at a size of 16 characters which is then increased by a power of two to handle larger amount of text. So with large amounts of text, this results in multiple re-sizing of the buffers which is inefficient.

This resizing of buffers most of the time only occurs once for any given string. There is another potential of resizing where if the text goes from lots of characters (over 1000) down to a few, the buffers will be resized to reduce potential excessive vertex attribute allocations.

With all the above said, I can more certainly improve / reduce these allocations for large text. I will try to improve this in subsequent releases of the TMP package.

 

Just wanted to provide an update on this...

I revised the handling of the allocations for these internal buffers used in the text parsing and layout process. This change will result in a significant reduction in allocations for new text objects that contain a large amount of text.

For example, a newly created text object that contains 16,864 Characters / 2500 Words would previously result in one time allocations of 204MB whereas the revised implementation 10.4MB.

Before


After


These gains are simply the result of eliminating / significantly reducing the number of times arrays are resized.

There is a performance gain as well.

These allocations include all the internal buffers + textInfo + geometry ... ie. everything.

This change will be included in the next release of the TMP package which will be version 1.5.0-preview.4 for Unity 2018.4, version 2.1.0-preview.4 for Unity 2019.x and version 3.0.0-preview.4 for Unity 2020.x.

P.S. Further improvements are still possible but no ETA on that yet.

 

Amazing work - well done.
We are currently creating a learning management system to teach English and we have literaaly hundreds of texts.
Will it be OK to use TMP or will the reulting apk be massive.
Most of our texts will have about 500-600 words. We may use 100 texts.
If TMP is no good, what other option is there for crisp text on a mobile, and PC too?

 

There should not be any issues. There are many studios with projects that contain 1000's of text objects.

 

I am having problems in my game by pasting large texts in an input field.
I'm using unity 2020 and TMP 3.0.6

Pasting 80K characters results in an 800Mb Allocation, where this memory also increase more if you repeat the process. I can reproduce the issue in an empty project too.

If I load this text in individual lines formed from TMP_Text, consumption seems a bit lower, but even so reserves about 600MB of RAM using around 2000 lines.

I am doing something wrong? Is it possible that TMP does not support the management of these large texts?
I attached some profiler screenshots in the moment of adding the text.



This is creating a single TMP_Text per line

 

Can you provide more insight on the use case for using an Input Field with such large amounts of text?

Is it purely for having the ability to select / copy / paste text?

In terms of allocations, there are allocations for each text object.

For instance, if the text object contains 15 characters, some internal buffers will be allocated to handle 15 characters. If the text subsequently grows to 32 characters, additional allocation will be necessary to handle this larger character count.

Buffers are allocated in blocks using power of two. For instance, if the text does go from 15 to 32, we will allocate for 64 characters (32 next power of two).

Provided a text object doesn't grow, no further allocations will be needed.

In terms of performance overhead. The larger the amount of text the more performance overhead. There isn't much overhead in dealing with text objects that contains a few dozen characters. However, text objects that contain 1000's of characters result in much more significant overhead.

Text component are more efficient than the Input Field.

Laying out large static text object has a cost but given they are static, this performance cost is incurred only once. Even then, I still recommend splitting the text into smaller logical blocks especially if not all the text is visible on screen anyway. Why waste layout time for stuff that is not visible?

Try to avoid dynamic changes to large blocks of text. This is where you incur the layout costs multiple times.

 

@Stephan_B Its not hard to reproduce performance issues.

1. Grab a "lorem ipsum" text with the character length of 600.
2. Use TMP_InputField, set the limit of lines to 100 and set readOnly to true.
3. Implement a re-cycle line input so the oldest line gets cleared out.
4. Implement a simple thread that adds a new line from 1. to the field.

Depending on your PC, you might reach 1 FPS before getting to line 50.

The main issue is that there is no alternative to using the TMP_InputField. Using TMP_Text doesn't make things that much better.

We are in 2023. AI bots everywhere. AI robots are even talking to us. But we can't create a UI containing a little bit of text using Unity.

I am working on a text-area that can be used for production without performance issues but I still wish that Unity would have had that already in the first place. I mean, when I started using Unity, I wanted to work on a game not basic things.

Sorry, but I am not very happy about the current state and looking at the recent code of TMP does hurt quite a lot.

 

I completely agree with this.
I am currently developing an app that sets up GPT4 Persona using Unity.
and this app requires a mass amount of RAW text chunks as input, and TMP still cannot handle this.

Of course, there is no problem if i use the legacy inputfield...
but the problem is that the place I serving is "Korea". Since the user inputs not only English but also Korean, so there is no choice but to use TMP.

Does anyone know alternative of TMP?