Unity version 2020.3.1f1
Target platform: Android
Player Setting: Graphics API ：VUlkan
FontAsset: check Clear Dynamic data on build
run on android device will cause a lot of memory increase.
but if built with opengl es graphic api, it won’t increase the memory.
Clear Dynamic Data on Build clears the font data and atlas texture of the font asset prior to building the player. Other than having this font asset empty as the app starts on Android, the memory overhead / usage should not have changed.
What version of the TMP package are you using?
Can you provide more information on your font asset by posting a screenshot of the font asset’s Generation Settings?
The fact that changing the graphic backend changes the behavior points to some potential graphic issue which would be exposed by TMP.
I’ll try to reproduce the issue on my end and if so get the graphic team to take a closer look at this.
Sorry, it’s not TMP font asset. It’s a normal font asset.
if the font asset’s texture atlas is empty, i mean if i clear all the characters in the atlas before i build android app, then the memory will increase a lot at run time, hundreds of MB, but if the graphic api is opengl es, the memory won’t increase.
So this is happening when using UI Toolkit or when using TextMesh Pro?
ui toolkit
Let me see if I am able to reproduce this behavior on my end.
I am still thinking this is graphic related issue as nothing changes on the TMP side or FontEngine side when the graphic backend changes.
Once I am able to reproduce this, I’ll have a better idea.
How are you tracking these memory overhead changes? Can you post an image of these two potential results for my reference?
i exported an android studio project. and run in android studio, profiling with android studio’s profile tool.
the img above is checked with clear dynamic data on build. It results a memory increase.
the img below isn’t checked with clear dynamic data on build.
Memory issue aside and out of curiosity, is this font asset used mostly for user input?
The atlas texture size is 2048 x 2048 with sampling point size of 30 and padding of 2 which means you can most likely add 1000’s of characters into that atlas. Given changes to dynamic font asset in builds are not persistent, ie they reset back to their default state for each play session, if this asset might only even contain a few 100 characters, then I would suggest reducing the atlas size to 1024 x 1024. This should indirectly reduce the memory overhead.
Can you post an image of what you are seeing on OpenGL with the same scene?
my ttf font is 8mb. it’s a chinese characters font. there are only 300-500 chinese characters on the scene when running.the atlas texture of size 2048x2048 is big enough. i don’t know why dynamicly build character atlas texture can cause so many memories increasing. but if build with opengles graphic api, it won’t cause memory issue.
if we run once on computer and let the font atlas texture contain all the characters of running scene. then run on android, this time it won’t generate characters dynamicly. this won’t cause memory increase. if characters aren’t contained in the atlas and need generate at runtime, this will increase memory.
Since you have Multi Atlas Texture enabled, this will result in additional atlas textures being created as needed when the current atlas texture is full.
Given you can fit about 1800 glyphs at an atlas texture of 1024 x 1024 with sampling point size of 30 and padding of 2, you are most likely wasting lots of texture space by using a 2048 x 2048 texture. Instead, I would suggest using a 1024 x 1024 still with Multi Atlas Texture enabled where in the event it gets full an additional 1024 x 1024 would be created automatically to handle the additional glyphs.
When a dynamic font asset is Reset which is what happens when you have Clear Dynamic Data on Build, its atlas texture is set to size zero. Ie. It take no space in your build. At runtime and when the first glyph is added to this texture, it is resized to whatever the Generation Settings specifies which in your case is 2048 x 2048. Therefore in your case, as soon as the first glyph is added, the memory overhead of this texture is 4MB x 2 since it is readable. By contrast, if you were to use a 512 x 512 when the first glyph is it would use 256KB x 2 until it is full at which point another 512 x 512 would be created.
Starting off at 512 x 512 might be too small if you quickly go from zero glyphs to over 400 glyphs otherwise a 1024 x 1024 should be plenty given it can hold over 1800 glyphs at those settings.
Again all of this is besides the memory issue related to the Graphic API selection which I am investigating.
i made a test project, you can export an android studio project, and see the memory increase in android studio profile tool.
6999389–827072–BugTest1.rar (4.89 MB)
i uploaded a test project above.
Thank you for providing the project.
I was able to reproduce the behavior where the System Used Memory when using Vulkan is significantly higher than OpenGLES3 with Clear Dynamic Data on Build enabled.
The same behavior happens with TMP font assets as well.
The only thing that changes when Clear Dynamic Data on Build is enabled is that the atlas texture is set to size 0 and then resized on first use. So perhaps there is some issue when resizing a texture when using Vulkan.
I’ll look further into this tomorrow.
The issue on Vulkan appears to be related to glyphs being added to the atlas texture at runtime. So something about modifying the atlas texture when using Vulkan is causing this.
The behavior can be observed when using “Clear Dynamic Data on Build” simply because it clears the atlas texture prior to build thus resulting in glyphs being added at runtime which is the source of the issue when using Vulkan.
Given the process of adding glyphs to an atlas texture at runtime is the same regardless of the Graphic API where we are not seeing this increase in memory overhead when using OpenGLES3, this points to a Vulkan specific issue.
I have submitted a bug report to the Vulkan team and will follow up once I get an update from them.
Hi, Stephan_B，the Vulkan team is Unity’s staff member??
Is there an exact time to fix this bug??
Yes. Let me see if I can get an update on this tomorrow.
:)，Is there any progress？？ “
” is this the problem???
It is not.
I am still waiting to hear back from the Vulkan team.
I will follow up as soon as I have more information from them.