Display real FPS in the 3D editor instead of estimating based on CPU/GPU time

[Calinou]

This reverts to the 3.x method for displaying FPS in the View Frame Time panel. This has two consequences:

• The reported FPS will no longer go past V-Sync or framerate limiters.
• Unfocusing the window will display a low framerate (10 FPS by default), since the FPS is actually being limited by the engine's low-processor mode. In general, in this situation, the current FPS estimate can't be expected to be accurate as the GPU will often downclock as a result of the low GPU utilization.

Constant redrawing is still forced while the panel is visible, so there's no risk of having low-processor mode interfere.

The engine's FPS readout is updated less smoothly than the current method, but this will be improved if #63356 is merged.

On the images below, the actual FPS (and GPU power consumption) is identical, but since I use a 120 Hz display with V-Sync enabled, the engine cannot go past 120 FPS:

Before	After

• See Impossible to limit frames, neither with v-sync, nor with max fps nor Nvidia limits, in Godot 4.0 #69218.

[clayjohn]

Looks good to me.

Can you confirm that in that same test scene with vsync off you still report 312 FPS?

As a note for the future, we bikshedded this feature a lot a few months back and never settled on something we were happy with.

In the end, I agree that it is best to not try to show "potential maximum FPS based on GPU usage". Users are interested in actual FPS and expect to see the amount limited by vsync.

[Calinou]

Can you confirm that in that same test scene with vsync off you still report 312 FPS?

With V-Sync disabled and Update Continuously enabled, the reported FPS is lower as the editor's redrawing cost is also included (instead of only counting the 3D viewport):

However, it might be argued that this value is more representative of the running project in fullscreen (which implies a larger viewport resolution than a maximized editor, even if the editor is fullscreen). When running the project (without the editor in the background), I get 250 FPS in fullscreen with the same camera angle as the editor.

[Riteo]

@Calinou

However, it might be argued that this value is more representative of the running project in fullscreen

IMO the non-problem factor is even higher. TBH, if I read 274 FPS I expect to see 274 FPS, indipendently of whether this is a technically slightly lower value than a "pure" game instance due to the editor drawing. One could argue also that even just having the editor in the same screen of the game (or anything else, tbf), will naturally lower FPS as there is more competition for resources, so IMO a real value is wayyy more useful and expected than an estimated value.

[clayjohn]

However, it might be argued that this value is more representative of the running project in fullscreen (which implies a larger viewport resolution than a maximized editor, even if the editor is fullscreen). When running the project (without the editor in the background), I get 250 FPS in fullscreen with the same camera angle as the editor.

Small Viewport + Editor redraw isn't a good metric for "FPS if viewport was fullscreen" as editor drawing potentially has very different performance characteristics to the running scene. Juan's original intention with this FPS value was to communicate "here is what FPS would be if this scene was running on its own and GPU was the bottleneck".

I'm not sure that overall editor performance is actually a metric that we should be reporting here

[Ansraer]

Maybe we could rename "FPS:" to "Editor FPS:"?

[Calinou]

Maybe we could rename "FPS:" to "Editor FPS:"?

Done (not shown on the above screenshots).