Why Does Unity UI Rendering Cost Stay High Even When the Screen Looks Simple?
During testing, we found that some gameplay screens do not look visually complex, but the runtime UI related overhead is still relatively high. There are no obviously large numbers of complex elements on the screen, so why does the UI cost remain high? What areas should we investigate to identify the root cause?
The key point is that visual complexity and actual UI rendering cost are not always directly correlated . Developers often estimate UI performance pressure based on how many images, texts, or controls are visible on the screen. However, Unity UGUI rendering cost is also affected by factors such as draw call count, UI hierarchy organization, and update frequency . Even if the final screen does not look crowded, a large number of independent UGUI rendering batches can still significantly increase rendering submission overhead. In the GameOptim GOT Online report, the peak number of calls for in the rendering module reached 394 times . In this report analysis context, the call count of this node can be used to observe changes in UGUI DrawCall count within the corresponding frames. In extreme cases, when UGUI DrawCalls reach 300–400 , it indicates that the number of UI rendering batches submitted by the project is already relatively high. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/b70e8be6 86fc 4fe9 b228 d842c4899fa5.png However, it is important to note that a high UGUI DrawCall count does not necessarily mean there are many visible UI elements on the screen . Some gameplay visuals may be implemented through UI components instead of traditional scene objects. When combined with UI effects, TMP text, and other UI elements, the number of objects involved in rendering and updating can become much higher than what is visually apparent. At this stage, the report alone cannot directly identify which specific UI elements are breaking batching. Further investigation requires combining project structure analysis with rendering debugging data. This issue is also reflected in CPU side UI processing costs. According to the report, the average CPU time spent on the UI module reached 7.85ms , indicating that UI is not only increasing rendering batch submissions but also consuming a significant amount of CPU processing time. For a game targeting 60 FPS , each frame has a total budget of approximately 16.67ms . If UI processing consistently takes nearly 8ms , it leaves much less time for gameplay logic, animation updates, and other rendering tasks. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/5390c67b bae3 4a48 bec7 378539ca6572.png Looking at the overall performance curve, the rendering module cost and UGUI related cost show a very similar trend. This correlation suggests that the current rendering fluctuations are strongly associated with UI activity. Therefore, investigation should not stop at the rendering module itself — the UI update workflow should also be examined. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/3537ed68 fa3d 4803 bb66 43a604b9f53e.png Within the UI module, the main performance entry point is . This process handles UI element updates and rendering batch rebuilding. When properties such as image color, text content, or other UI attributes change, the related Canvas needs to update its rendering data. Complex and frequently updated objects such as UI Particle effects and TMP text can also increase UI update overhead. If you need to identify which specific UI elements are frequently triggering Canvas updates, you can add instrumentation around the process. https://uwa overseas public.oss us east 1.aliyuncs.com/uploads/markdown/aed6f6b3 15d1 45c9 857b 4b81d53effa1.png By recording the UI objects that trigger updates during runtime, developers can identify which elements are continuously forcing Canvas rebuilds. After locating these objects, further optimization can be performed based on their hierarchy structure, update frequency, and usage patterns. Another common issue occurs when dynamic UI elements and large amounts of static UI are placed under the same Canvas . In this situation, even a small UI change can expand the update impact range and cause unnecessary rebuild costs. Therefore, optimization should not focus only on "removing some UI elements." Instead, it should address two separate areas: Rendering batch optimization: Use rendering debugging tools to analyze UI batching behavior and identify unnecessary batch breaks or excessive DrawCalls. UI update optimization: Identify frequently changing, activated, or hidden UI elements, and separate them from static UI where appropriate to reduce the scope of Canvas updates. By optimizing both rendering batches and update workflows, developers can significantly reduce unnecessary UGUI overhead while maintaining the required visual quality.