Performance metrics
March 1st, 2015
Performance is interesting because it very often doesn't matter. Even the worst application running on the most terrible hardware doesn't need optimizations as long as the performance is acceptable. The rule is: if improving performance would not be noticeable to the player, then any time spent improving performance is a complete waste. That time is always better spent on things noticeable to the player.
This doesn't mean performance should be ignored during development, only that minimal performance considerations should be made as preemptive attempts to avoid performance problems. It's very easy to go too far and waste time, especially when so many variables are involved:
- what hardware the application is running on,
- everything done by the application and game toolkit besides rendering Spine animations,
- how the game toolkit and Spine runtime perform rendering,
- how many skeletons are rendered,
- how those skeletons are configured,
- how many pixels are drawn,
- and much more.
When designing Spine animations, ideally animators take all of this into account and only deliver assets that perform well. In reality, animators tend to feel very alone in a big universe and often build animations without considering how it impacts runtime rendering.
To help with this, we've added the Metrics view:
This shows a number of metrics that can help give an idea of how expensive skeletons will be to render at runtime, both for the CPU and GPU. You can read more about each individual metric on the Metrics page of the Spine User Guide, but I'll mention a few of the most important numbers here.
The number of bones, constraints, timelines, and vertex transforms all contribute to CPU usage. Vertex transforms tend to be the highest, especially when using mesh weights. Meshes should use the lowest number of vertices to deform the mesh as required.
Area gives some indication of how many pixels are drawn, assuming the skeletons are drawn at full size. This can help determine how the skeletons impact the fill rate.
Even with the Metrics view, performance relies on so many variables that it isn't possible to generalize about which numbers are too high. You will need to perform your own tests using your actual skeletons on a variety of hardware to get an idea of the limits in your environment. Even then, if you aren't pushing the CPU or GPU to its limits, then there is no need to waste time stressing about performance or to sacrifice the quality of your animations.
Discuss this post on the Spine forum.