Godot: Text rendering performance low due to missing batching
Godot version:
Godot 3.1 compiled with 54988df9ce0227d9f933f6f82e2f9f1d35df28c0
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
All 22 comments
@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.
Geequlim
on 2 Jul 2018
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.
mrcdk
on 2 Jul 2018
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 notifications@github.com wrote:
Godot version:
Godot 3.1 compiled with 54988df
https://github.com/godotengine/godot/commit/54988df9ce0227d9f933f6f82e2f9f1d35df28c0OS/device including version:
Android 7.1.2
Qualcomm® Adreno™ 430 GPU OpenGL ES 3.1Issue 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.jpgSteps 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
https://github.com/godotengine/godot/issues/19917, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z24mQHDJim8J0pn1hlZFZKjPIU9VMks5uClhRgaJpZM4U_rel
.
reduz
on 3 Jul 2018
Related issues:
https://github.com/godotengine/godot/issues/5838
https://github.com/godotengine/godot/issues/11797
mhilbrunner
on 5 Jul 2018
@Geequlim Would you have a test project to share for @dragmz to test their text batching WIP?
akien-mga
on 20 Jul 2018
@akien-mga Of couse yes
Geequlim
on 20 Jul 2018
@dragmz You can download this project for testing
text_rendering.zip
Geequlim
on 20 Jul 2018
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.
dragmz
on 20 Jul 2018
Reopening as #20965 was reverted in #21204.
akien-mga
on 20 Aug 2018
@akien-mga did we not merge a new batching afterwards?
reduz
on 7 Sep 2018
No, #20965 was the "new" batching (the previous one was never merged, it was rejected).
akien-mga
on 10 Sep 2018
Hold my beer! :sunglasses:
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
lawnjelly
on 5 Feb 2020
What are the steps to get this working for gles3? Although it is going away...
fire
on 5 Feb 2020
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
on 5 Feb 2020
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.
lawnjelly
on 5 Feb 2020
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.
fire
on 5 Feb 2020
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.
burstina
on 6 Feb 2020
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.
lawnjelly
on 8 Feb 2020
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
Can now test my batching PR on Android, debug build, same test as before, on a Google Nexus 7 2012:
400: 13fpsThat's 5.3x speedup.
burstina
on 11 Feb 2020
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
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)? :blush:
lawnjelly
on 12 Feb 2020
They aren't specifically to address text rendering.
Oh well, I told you I am a newbie 😄 Infact I understood wrong ðŸ’
burstina
on 12 Feb 2020
This should have been closed when #37349 was merged.
clayjohn
on 21 Jun 2020
Related issues
bojidar-bg
·
3Comments
n-pigeon
·
3Comments
rgrams
·
3Comments
SleepProgger
·
3Comments
RayKoopa
·
3Comments
Most helpful comment
Hold my beer! :sunglasses:
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