Search Issue Tracker
Fixed in 2022.2.X
Votes
7
Found in
2018.4
2019.4
2020.3
2021.1
2021.1.5f1
2021.2
Issue ID
1334548
Regression
No
GFX memory usage in editor is significantly higher than in player when updating Canvas Renderer's meshes with setMesh
Reproduction steps:
1. Open the attached project ("case_1334548.zip")
2. Open the "SetMeshScene" scene: Project window > Assets > "SetMeshScene.unity"
3. Open the Profiler window: Window > Analysis > Profiler
4. In the editor, click play, and wait for 15-45s
5. Inspect the Profiler window, Memory tab
Expected result: The GFX memory (RAM) usage in editor should be reasonably close to memory usage in player
Actual result: The GFX memory (RAM) usage reaches 2.5GB in editor, while in player - 9.8MB
Reproducible with: 2018.4.35f1, 2019.4.28f1, 2020.3.11f1, 2021.1.10f1, 2021.2.0a19
Comments (1)
-
Tapuzi
Jun 12, 2021 17:30
Best issue on this site
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
- Crash on ResizeScriptingList<ScriptingObjectPtr> when passing an undeclared variable to the results parameter for GameObject.FindGameObjectsWithTag
- [Android] "Screen.safeArea.y" always returns values outside of the Safe Area when the device is in Portrait orientation
- Frame spike due to many TreeRenderer.TreeUpdated calls when repositioning terrains in large Scenes
- Crash on GameObject::RemoveComponentFromGameObjectInternal when reparenting Text GameObjects
- [IL2CPP-GarbageCollector] Changing GCMode might permanently disable GC in a multithreaded context
Resolution Note (fix version 2022.2):
Fixed in 2022.2.0a17
This is caused by the UI profiler capturing every frame. It holds onto the graphics buffers (by design) which means that when SetMesh is called a new buffer needs to be created each time. This increase should slow down once the max number of profiler frames is captured however there is a bug with the profiler Clear button is not clearing the captured frames which we fixed.