Optimizing CPU-side Rendering Code

Godot is continuing to optimize the CPU side of its renderer, and one recent Polygon2D investigation shows how quickly a seemingly small scene can become expensive. In a test on a Ryzen 5 9600X, a setup with roughly 20 animated characters was already hitting a wall, with 15.7 ms spent in Polygon2D::_notification() and another 11.7 ms in drawing work.

The key issue was not just animation cost. The renderer was repeatedly creating and freeing vertex arrays every frame, with about 3.3 ms spent building them and 5 ms spent freeing them. That kind of churn is exactly the sort of hidden overhead that can make a game feel inexplicably slow even when the GPU is not the main problem.

The broader takeaway is that renderer optimization is a process of profiling, understanding the bottleneck, changing the code, and then measuring again. Godot is using external profiling tools like Superluminal alongside its own editor profilers and Tracy support to track down these CPU hotspots. For developers, every engine-side win translates into more headroom for gameplay, animation, and content on the same hardware.

This also reinforces a practical rule for engine work: CPU and GPU tradeoffs have to be balanced per use case. 2D batching, 3D occlusion culling, and mesh rebuild behavior all affect where the frame time goes, and the wrong choice can quietly dominate performance long before a project looks technically demanding.