One of the main gripes with KWin's composite support over the years is
for me the FPS effect. For developers it doesn't provide useful
information as it triggers constant repaints. This just doesn't match
how KWin actually renders. For users it's also not a good solution as it
shows multiple problems:

• due to being graphical it influences the measurement
• it is capped at 100 Hz which is not sufficient for 144 Hz screens
• it is integrated into the effects system which is not deep enough to

properly measure

While the 100 Hz problem is solvable the general problem remains: the
fps effect is not showing the reality and this is unsolvable. Also we
see that users reference this effect a lot in bug reports and this is to
me a problem.

With this patch I try to address the problem by properly recording the
rendered frames in the compositor. It's kept simple and just puts the
timestamp in a queue with a max size of 5 sec at 144 Hz. In practice
this captures a longer time frame as KWin doesn't render that many
frames.

For a start the information is put into support information, but not as
fps. Fps makes IMHO no sense in KWin. So it shows the number of frames
and the duration in msec. A user could calculate the fps from it, but as
said, that's pretty useless. To indicate this an explanation text is
added.

The chosen architecture allows to do more in future. One could for
example extract the framerate of the last second or constantly updating
the fps as a sliding average. The current implementation is inspired by
glxgears which just prints out the number of frames over the last five
seconds.