Use case:
Since the renderer tries to display as many frames as possible, it will always induce 100% CPU workload on that core without benefit.
Not a direct concern of 0A.D., but it can also overheat hardware if throttling was disabled (as experienced by MojoRising420).
Implementation:
rP16927 / #2882 addressed this issue for main menus. But it is insufficient:
- It doesn't apply to running games.
- It doesn't allow the user to chose a target FPS.
- It renders about 20% too few FPS when picking a higher framerate
- It doesn't actually limit the FPS, because it only considers the time consumed by the most recently rendered frame, while the framerate fluctuates.
The inaccuracy in 3. derives from the frequency filter framerates (SmoothedFrequency, StableFrequency, AverageFrequency).
Instead, measuring the milliseconds since the last call gives a correct result.
An actual FPS limiter might be useful as well, as there can be screen tearing with Vsync disabled and input lag with Vsync enabled.
Never seen any of either though, likely due to the window manager doing Vsync already.