Text rendering performance low due to missing batching

[Geequlim]

Godot version:

Godot 3.1 compiled with 54988df

OS/device including version:

Android 7.1.2
Qualcomm® Adreno™ 430 GPU OpenGL ES 3.1

Issue description:

Text rendering harms the FPS on Android with GLES3.
In the screenshots below the same scene rendered with diffrent text content.
More text rendered less FPS.

Steps to reproduce:

• Create a RichTextLabel and fill a long text as its text
• Export and run it on Android with GLES3

Minimal reproduction project:

[Geequlim]

@akien-mga I don't think this problem is only for Android. It is more obviously on Android as it can't reach 60 FPS.
If I didn't limit the max FPS to 60 on my Linux desktop. The FPS can still down with the large text scene.

[mrcdk]

2D doesn't batch anything so each character is a draw call. It looks like you are working on an app so enabling low processor mode would make it only render when needed.

[reduz]

Been discussing for a while the idea of batching text, which is also needed for other stuff such as drawing text outlines

…

On Mon, Jul 2, 2018 at 2:28 PM Geequlim ***@***.***> wrote: *Godot version:* Godot 3.1 compiled with 54988df <54988df> *OS/device including version:* Android 7.1.2 Qualcomm® Adreno™ 430 GPU OpenGL ES 3.1 *Issue description:* Text rendering harms the FPS on Android with GLES3. In the screenshots below the same scene rendered with diffrent text content. More text rendered less FPS. [image: screenshot-1530551860525] <https://user-images.githubusercontent.com/6964556/42177581-ceaa8fd4-7e5f-11e8-8645-c76a087a1e3a.jpg> [image: screenshot-1530551712802] <https://user-images.githubusercontent.com/6964556/42177594-daba4cba-7e5f-11e8-91a7-01b8df5883eb.jpg> *Steps to reproduce:* - Create a RichTextLabel and fill a long text as its text - Export and run it on Android with GLES3 *Minimal reproduction project:* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19917>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z24mQHDJim8J0pn1hlZFZKjPIU9VMks5uClhRgaJpZM4U_rel> .

[mhilbrunner]

Related issues:
#5838
#11797

[akien-mga]

@Geequlim Would you have a test project to share for @dragmz to test their text batching WIP?

[Geequlim]

@akien-mga Of couse yes

[Geequlim]

@dragmz You can download this project for testing
text_rendering.zip

[dragmz]

Thanks @Geequlim

Here are my first results for GLES2: (batching vs master FPS with given number of "Add More Text"
clicks):

1024k RAM vertex buffer

Empty: no change
100 "Add More Text" clicks: 175 vs 53 [~3.3]
200: 65 vs 28 [~2.3]
300: 35 vs 19 [~1.8]
400: 21 vs 14 [~1.5]
500: 14 vs 12 [~1.2]

10024k buffer

100: 250 FPS
200: 150
300: 104
400: 73
500: 61

That's on Intel GPU. I should be able to test on Android but that may take me a few days.

[akien-mga]

Reopening as #20965 was reverted in #21204.

[reduz]

@akien-mga did we not merge a new batching afterwards?

[akien-mga]

No, #20965 was the "new" batching (the previous one was never merged, it was rejected).

[lawnjelly]

Hold my beer! 😎

This is the result of my new batching (PR coming soon) with the text_rendering.zip test project posted above, in GLES 2 on desktop (similar gains on Android though):

I rigged it so that each press added 100 lots of the text instead of 1 (I'm guessing this is what dragmz was doing).

Debug build

Godot 3.2

No clicks 1560 fps
100 clicks 20 fps
200 clicks 10 fps
300 clicks 7 fps
400 clicks 5 fps

Godot 3.2 + new batching

No clicks 2050 fps
100 clicks 298 fps
200 clicks 168 fps
300 clicks 117 fps
400 clicks 89 fps

Sorry had a methodology error in my first set of figures, these should be more accurate. Note these are both for debug builds.

Edit - I've now done a test with release build and a few more tweaks. As I suspected, the speed gains in release are even higher:

Release_Debug

Godot 3.2

500 clicks 5fps

Godot 3.2 + new batching

500 clicks 291fps (58x speed increase)

This is on Intel Core i5-7500T CPU
Intel HD Integrated Graphics 630 GPU

[fire]

What are the steps to get this working for gles3? Although it is going away...

[lawnjelly]

Although the interesting thing is the rich text should probably cull away the text that isn't on screen, and if this were working, there would in theory be no performance drops after about the 8th click. Still kind of useful as a benchmark.

[lawnjelly]

What are the steps to get this working for gles3? Although it is going away...

Looks pretty simple actually, that part of the renderer is pretty similar, almost a copy and paste job.

[fire]

I and others who use 2d menus in 3d games on mobile gles3 would very appreciate this! I hope it isn't too hard to do in the same pr. Thanks.

[burstina]

Meanwhile You can use FastText asset. It is a little workaround I did for my projects and it works perfeclty on both Android and desktop. No watchable frame drops for 1000 FastText labels stress test.

[lawnjelly]

Can now test my batching PR on Android, debug build, same test as before, on a Google Nexus 7 2012:

Godot 3.2 without batching

0: 60fps
100: 7fps
200: 3fps
300: 2fps
400: 1fps

Godot 3.2 with batching

0: 60fps
100: 37fps
200: 24fps
300: 17fps
400: 13fps

That's 5.3x speedup.

[burstina]

Good, but if it is an engine builtin text batching, my newbie opinion is that it could be improved: look at this custom GDscript text batching running on Android video

FastTextStresstest.zip

Can now test my batching PR on Android, debug build, same test as before, on a Google Nexus 7 2012:
400: 13fps

That's 5.3x speedup.

[lawnjelly]

Good, but if it is an engine builtin text batching, my newbie opinion is that it could be improved: look at this custom GDscript text batching running on Android video

FastTextStresstest.zip

You are absolutely right, if you mean caching the text as an image. However this isn't what these batching PRs do, they are lower level and intended to accelerate all rects (and eventually all primitives), and letters are still ultimately drawn one at a time. They aren't specifically to address text rendering.

There could be an argument to add the caching you suggest in core (many GUI systems do this for text and other elements), you could propose it on godot proposals (if it is not there)? 😊

[burstina]

They aren't specifically to address text rendering.

Oh well, I told you I am a newbie 😄 Infact I understood wrong 💭

[clayjohn]

This should have been closed when #37349 was merged.