Use frame time not frame rate when working on performance

2016-06-18 17:00 CET nicolas@uucidl.com

Hi, I've heard you were working on an interactive graphical application, and that you're doing your best to give it a smooth frame rate.

Here is a piece of advice about measurements. Try to ignore changes in frame rate when measuring and tracking the performance of a component within the complete system. Remember instead your frame time budget (e.g. 16ms for a 60hz target) and track the time your component takes within that budget.

You should see why when looking at the relationship between your efforts and the measurements.

Since frame rates are inversely proportional to frame times, for the same optimization (a delta in time: Δ_t), you will observe different frame rate deltas when you start from different frame times. (e.g. in different testing conditions or if the system changes)

Δ_t=

4

ms Max(time)=

80

ms

This comes directly from the definition: rate_hz = 1/time_s. Since it is non-linear, rates in hz for various subcomponents cannot be added to one another. Frame times however can be added and be used to predict the performance of the resulting system.

To deliver a smooth experience, what matters is whether your complete system will consistently meet its per-frame budget, such as 16ms for a 60hz target.

That budget is best monitored with deltas in time, as for given workloads the deltas can be added to predict the overall performance of the system.