Improved FPS calculation

[DedeHai]

This improvement is for dev purposes mainly but it also gives a bit smoother FPS return values in normal builds.

Changes:

• fixed point calculation for improved accuracy, 9.7 bit, so max FPS can be 511
  - dithering (in debug builds only)
• averaging and optional multiplier can be set as compile flags

Example for speed testing with long averaging and a 10x multiplier:

-D FPS_CALC_AVG=200
-D FPS_MULTIPLIER=10

Since the calculation resolution is limited (9.7bit fixed point) FPS_CALC_AVG values larger than 200 can hit resolution limit and get stuck before reaching the final value.

If WLED_DEBUG is defined, dithering is added to the returned value so sub-frame accuracy is possible in post-processing without enabling the multiplier.

[softhack007]

@DedeHai looks very good for me, thanks. Two questions

• the max possible value of 200FPS is due to uint16_t _cumulativeFps, right? so in case i wanted more, changing _cumulativeFps to uint32_t would be enough?
• to use a higher resolution time (like ESP.getCycleCount()) is just a matter of scaling diff and fpsCurr appropriately? or would it be better to also increase fixed-point resolution in that case?

[DedeHai]

• the problem is resolution, I don't remember exactly which part causes the problem, but it is a standard problem for fixed point low pass filters. You do not want to crank up the number past 200 anyway, the time constant is roughly 6 times larger, so at 200 with 100FPS it takes over 10 seconds for the value to reach the targetvalue. 400 may still work, did not test. I slightly changed the code I used before for this PR, for me, I used 8.8 math but I thought 255FPS maximum may be exceeded in the future
• if you want more smoothing then yes, you need to increase it to 32bit AND (more importantly) increase the bit shift (and adjust what "0.5" is with the new shift). I really don't think its necessary though, if your FPS are so unstable that an averaging over like 10 seconds does not give you accurate numbers, you may have a different issue there...
• the time resolution is irrelevant, FPS are always in seconds ;) but yes, just need to adapt some values to match. The filter I implemented here (or I must say extended, it was the same before) is universal: value in = value out, as long as there are no overflows.

edit:
I realize now that you wrote 200FPS max. the limit is 511FPS. If you need more, you can go 32bit or reduce the bit shift to 6. The 200 limit mentioned is for FPS_CALC_AVG and its not a hard limit, nothing breaks really, just the filter will not reach the final value.

[softhack007]

edit:
I realize now that you wrote 200FPS max. the limit is 511FPS.

Thanks for your explanations. I think 511 FPS is future-safe for a long time ;-)

[DedeHai]

just for reference: I use this to check FPS in my tests https://pypi.org/project/wled2graph/

[softhack007]

Maybe replace all places with "7" by a constant (#define) ?

Its better for maintainability to leave a hint what the magic number "7" stands for - in this case the fixed point fraction bits.

[DedeHai]

done.

[softhack007]

Looks good 👍 I approve

Actually the old FPS code was always "broken" in a sense that it stops converging to real FPS when the delta is below 2. So we could see this as a bugfix that would fit into 0.15.