Add a project setting to limit FPS on focus loss

[Calinou]

Alternative implementation of #47812 (it turns out I forgot about that PR). See also #76987.

This is enabled by default to save power automatically and improve editor performance if the project is running in the background.

• This closes Add a FPS limit for unfocused and minimized windows to decrease CPU/GPU usage godot-proposals#2001.

Testing project: test_max_fps_on_focus_loss.zip

[RandomShaper]

Haven't checked deeply, but I think the editor already enters low processor mode on focus lost. Would we have after this PR two different code paths addressing the same issue?

[Calinou]

Haven't checked deeply, but I think the editor already enters low processor mode on focus lost. Would we have after this PR two different code paths addressing the same issue?

The editor already has its own FPS limiting routine based on low-processor mode (which is always enabled unless you have Update Continuously enabled in the Editor Settings). This is why the code is guarded with if (!Engine::get_singleton()->is_editor_hint()).

We could merge these codepaths together in the long run by removing the editor's implementation and making it use the project code.

[akien-mga]

I have some concerns about this:

• This applies both when running the game in the editor, and when running the game once exported. Is it common behavior for games to throttle FPS when unfocused? I don't remember seeing that much, and I can see it be problematic for games which have logic that needs to stay synced with the ticks (timers, etc.).
• During development, I think this would actually become a hindrance because I typically run the game windowed and alt-tab back and forth between the game and the editor. If the game throttles every time the editor gets focused, using the remote scene tree and the profiler becomes unreliable. The added prints for each focus change will also quickly get annoying.

[lawnjelly]

print_verbose might be better?

[Calinou]

It's already encapsulated in is_stdout_verbose(); print_line() within is_stdout_verbose() is equivalent to print_verbose(). I did this to prevent conditions from being evaluated when --verbose is not used.

[lawnjelly]

Possible problem with the logic here:

If you set a max_fps, low_processor_mode etc when not focused, and record the old one, what happens if the user changes these before you swap back? I don't know if these can be set at runtime, but if they can, it's possible to get out of sync.

Common solution for this problem is to maintain e.g. a focused and unfocused max_fps in the OS, and have a flag for whether focused, and just return the relevant one depending on the flag.

[Calinou]

I don't remember seeing that much, and I can see it be problematic for games which have logic that needs to stay synced with the ticks (timers, etc.).

This can be an issue indeed. We could increase the maximum amount of physics ticks simulated per frame when the window is unfocused to avoid this issue. The default is 8; we could increase it to 48 when unfocused by default (assuming you'd be running at 60 FPS when focused).

As for timers, we should add a way to make them able to emit their signals multiple times in a single frame. This will need to be opt-in on a per-Timer basis to avoid performance issues, and also to preserve compatibility with existing projects.

I don't know if these can be set at runtime, but if they can, it's possible to get out of sync.

These can be set at run-time.

Common solution for this problem is to maintain e.g. a focused and unfocused max_fps in the OS, and have a flag for whether focused, and just return the relevant one depending on the flag.

Indeed, it would be better to have a property at the Engine level for this (like I did for #66367).

[Calinou]

Closing in favor of #47812, which is a more robust implementation.