Clarify that the FPS displayed in the 3D editor viewport is estimated

[Calinou]

See https://github.com/godotengine/godot/issues/69218.

It may be a good idea to implement CPU/GPU utilization queries in Godot, so we can display the CPU/GPU usage percentage in this panel as well. This way, you can see whether your CPU/GPU are being fully utilized or not.

[akien-mga]

I'm slightly concerned that the "(est.)" abbreviation might not be obvious to all users (it seems to be a valid one though: https://dictionary.cambridge.org/dictionary/english/est), but most importantly that it might be pretty difficult to translate while keeping it short (for example I can't find a good option for French).

[Zireael07]

Maybe use "~X fps" or "circa X fps" instead? Circa comes from Latin and is pretty universal, and the tilde even more so.

[fire]

I like the (symbolic) tilde suggestion rather than an language suggestion too.

[clayjohn]

I'm not sure if "estimated" is really what needs to be conveyed here. "Estimated" conveys to the reader that the value is close to the correct value, but is not exact.

The confusion OP had in https://github.com/godotengine/godot/issues/69218 is not that the results were inexact, but that they didn't take vsync into account and so they were completely different from expected. For example, with a simple scene users may see a frame time of 1.5 ms even with VSync enabled (so it should be 16.66 ms). Reporting "~1.5 ms" isn't really an improvement here because the value is off by an order of magnitude.

[fire]

Can we estimate how bad the estimate is?

[deralmas]

@fire We might as well try to calculate it better, otherwise we'd also have to estimate how bad the estimate estimation is :P

[Ansraer]

Can't we just check if (fps > vsync && vsync_enabled) and if true just display vformat(TTR("FPS: ~%d (VSync)"), vsync) instead?

[Calinou]

Can't we just check if (fps > vsync && vsync_enabled) and if true just display vformat(TTR("FPS: ~%d (VSync)"), vsync) instead?

To do this accurately, we'd need to keep track of the current monitor the editor is on, so that we can accurately pick the refresh rate of the monitor the editor is currently on (for multi-monitor setups with different refresh rates). We should avoid querying the monitor refresh rate every frame when displaying the label, as it can be an expensive operation.

Alternatively, we can pick the highest refresh rate of all monitors on startup as a basis, but this will be inaccurate on some setups.

[clayjohn]

I guess Ideally we would have two reports:

1. FPS (uncapped)
2. FPS (actual)

Then it would be more clear what is actually happening.

Alternatively, we could just get rid of the FPS report altogether

[Calinou]

• Superseded by https://github.com/godotengine/godot/pull/75512.