FPS method calculation issue

[baryluk]

Some time ago I discovered MangoHud uses rather primitive method of computing fps.

It simply accumulates frametimes and number of frames accumulated, and reset it every 500ms (fps_sampling_interval).

While this is somehow useful, simple and does provide some benefits, for example it is not stuck computing very long average, or react too slowly to long frametimes, it also has undesirable effects if one wants to look at very accurate measurements.

The issue is that 1-3 first samples after the reset would have a very high variance, and would not be statistically significant, leading to serious spikes in average every 500ms.

For example, if the app is running at exactly 60fps, but the frametimes measured by mangohud oscilate a bit around 16.67ms, like this (which is common, for many reasons):

(these are raw frametimes for each frame when running glxgears with vsync under X11).

Using 1/fps logged from the same run over same period we got this:

I implemented a fix, that uses a circular buffer of up to 64 last frametimes and computes average over it, with an adaptive algorithm, that uses less samples, if needed, (i.e. it would use more than 300ms of of samples).

It looks the like this:

And here is a direct comparison:

(You can see the spikes every 500ms in old method due to the average restart).

The Work-In-Progress code is my branch https://github.com/baryluk/MangoHud/tree/fps-calc-fixes , with primary logic here: https://github.com/baryluk/MangoHud/blob/fps-calc-fixes/src/overlay.cpp#L75

I will polish the patch a bit, and do tests on more realistic titles, as well test the edge conditions, but I believe the accuracy and statistical improvements are significant.

[Atemu]

@baryluk did you ever get around to proposing a PR?