Add a FPS limit applied when the project window is unfocused or minimized

[Calinou]

This helps decrease power usage while the project window is unfocused or minimized.

The default FPS limit is 10¹. It can be disabled by setting the application/run/max_fps_when_unfocused project setting to 0.
The FPS limit is disabled by default when running the project from the editor to avoid interfering with profiling tools.

This closes godotengine/godot-proposals#2001 and closes #19741.

This PR can be remade for the 3.x branch if we reach an agreement on it.

Testing project: test_fps_limit.zip

Footnotes

1. I've decided to go with 10 instead of 20, because 20 doesn't result in sufficient power savings on low-end machines that already struggle with rendering projects at 30-40 FPS. ↩

[realkotob]

I would like this feature 👍

Has it been discussed off-github?
Is there a reason it was not merged (other than that there are thousands of PR 😅)

[Calinou]

Has it been discussed off-github?

Not that I know of.

Is there a reason it was not merged (other than that there are thousands of PR sweat_smile)

The PR is lacking a review 🙂

The proposal itself seems to have reached consensus (with 18 👍 reactions as of writing and no comments opposing it).

[reduz]

The problem with this is that if you are profiling, the window it will break the profiler. This would need to be disabled by the editor or via debugger protocol.

[Calinou]

The problem with this is that if you are profiling, the window it will break the profiler. This would need to be disabled by the editor or via debugger protocol.

Maybe I could add an .editor feature tag override for the unfocused FPS limit, setting it to 0 (no limit) there? This means the unfocused FPS limit would only be used in exported projects by default.

Edit: Done 🙂
I tested it and made sure the unfocused FPS limit no longer applies when running the project from the editor by default.

[akien-mga]

We discussed this in a PR review meeting and were not fully convinced yet by the approach. It feels like this adds something that can indeed be useful but this might require more thinking to make sure it works well and matches users' expectations (also to be assessed together with the existing low CPU mode option).

[Mickeon]

2 years have passed. Has something changed that would make this PR more robust with the profiler?

[Calinou]

Has something changed that would make this PR more robust with the profiler?

This PR no longer affects the running project if it's being run from an editor build, so the profiling issue should be resolved for the local profiling scenario now.

However, remote profiling deploys a debug export template which would have the FPS limit applied. Perhaps we should make it only apply to release export templates instead to avoid this.

I think ideally, the editor debugger should signal when the profiler (or visual profiler) starts so the running project disables the unfocused FPS limit (and restore it when all profilers are stopped).