Search Issue Tracker
By Design
Votes
0
Found in
2019.2.12f1
2019.3
2020.2
Issue ID
1224127
Regression
No
Sprite Renderer increasingly allocates memory when SetTrigger() is called every frame
How to reproduce:
1. Open the "Launch" Scene in the user-supplied project
2. Enter Play Mode
3. Observe Unity's memory usage
Expected result: the memory usage does not increase over time
Actual result: memory usage increases from ~400 MB to 3.5 GB in around 5 minutes and keeps increasing
Reproducible with: 2018.4.20f1, 2019.2.21f1, 2019.3.8f1, 2020.1.0b4, 2020.2.0a5
Could not test with: 2017.4.38f1
Notes:
1. User noted that when the Sprite Renderer component is swapped with the Image component, the memory load is not as large.
2. Reproducible in Play Mode, iOS.
3. iOS application crashes quickly due to a heavy memory load.
Comments (2)
-
BeatMicrosoft
Sep 24, 2020 13:18
I don't think you give me the right explanation. why so huge different? why namely mesh data so huge?
does spriterenderer need the mesh data? finally, we use a plugin called "spine".slove our problem.why it does not generate mesh data? and work perfectly? why unity don't have another component to solve this problem?
I think this is a unity design bug.we can't reduce the animation ,because we have a lots of player in scene.we need to load them.
I will report it again,until your slove this problem
-
BeatMicrosoft
Mar 31, 2020 18:18
Even every second call , the memory also will increase slowly. then heavy memory crash
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Editor Perforce login fails when Perforce shows a license expiry warning
- Assertion failed error in HDRP builds when enabling STP via script
- FBX Resamples Curves incorrectly when importing FBX files
- ProBuilder GameObject Faces disappear when increasing the Sides Count value
- FileUtil.CopyFileOrDirectory throws IOException when destination parent folder does not exist
Resolution Note:
After a close inspection of the repro project, we came to the conclusion that all the behaviors you see regarding memory consumption are expected. Let us answer your questions in detail.
Q: Why does the Sprite Renderer seem to continue allocating memory even after all the assets in the asset bundles are loaded?
A: Because some data of the sprites (namely mesh data) is only generated when they are first rendered by a Sprite Renderer. The Image component doesn't use a sprite's mesh data therefore doesn't incur this extra allocation. In the repro project, a set of sprite animations is randomly chosen to play every few seconds, meaning there are always never-before-seen sprites popping up at first, causing memory footprint to continuously grow. However, as more sprites show up, the allocation will eventually stop when every single sprite is drawn at least once.
Q: Why is the memory footprint so large that the app exhausts the RAM of the device and crashes?
A: Simply because you are trying to load too many assets at the same time. According to our test, the project tries to load more than 15K animations clips and 65K unique sprites all at once. With such huge amount of assets, you have to employ a better loading strategy than loading everything upfront.
Q: Why doesn't the Profiler show the actual memory consumption?
A: The extra allocations needed by sprite mesh data are partially handle by the graphics driver, and we don't think Unity Profiler tracks this kind of allocations accurately. This is definitely something we can improve in the future. Actually, we are making a new Memory Profiler and it's currently in preview and available via the Package Manager. More info here: https://docs.unity3d.com/Packages/com.unity.memoryprofiler@0.2/manual/index.html