Performance `TIME_PROCESS` doesn't report correct value when Project Setting's `application/run/max_fps` is set to zero or >= monitor refresh rate.

[pegasusearl]

Feature Link: https://docs.godotengine.org/en/stable/classes/class_performance.html

Tested versions

v4.6.2.stable.official [71f334935]

System information

Godot v4.6.2.stable - Windows 11 (build 26100) - Multi-window, 1 monitor - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 4060 (NVIDIA; 32.0.15.6636) - Intel(R) Core(TM) Ultra 7 265K (20 threads) - 47.27 GiB memory

Issue description

When application/run/max_fps in Project Settings is set to 0, or set to value equal or above the monitor's refresh rate, the Performance.get_monitor(Performance.TIME_PROCESS) doesn't seem to give us the correct frame time, but instead time between render frame, like delta in _process().

When this value is giving correct value, it can be useful to maintain steady fps by adjusting graphic settings.

Steps to reproduce

1. Open the MRP with Godot.
2. Run the project.

Since max_fps is currently set to 0, the time process label will show you the wrong number.

1. Now stop the project.
2. Go to Project Settings > Application > Run.
3. Set Max FPS to any number between 0 to your monitor's framerate (exclusive). For example if your monitor is 60hz, change the value to 59.
4. Now run the project.

Now it will not show delay between frames, but instead a small number, which I assume is the correct frame's render time.

Minimal reproduction project (MRP)

godot-perfmon-bug.zip

[AThousandShips]

From looking at the code this looks correct, and I'd say it matches the description:

Time it took to complete one frame, in seconds.

[pegasusearl]

From looking at the code this looks correct, and I'd say it matches the description:

Time it took to complete one frame, in seconds.

I don't think so, then it'd be not much different from delta time then.

Let's say we have 60hz display.

The delay between frame might be 16ms, but it doesn't take 16ms to process the frame right? This small value is what I was looking for.

If the current one is correct, then there is no equivalent feature that show how long the frame took to process. Which is very useful feature, and will probably a feature request instead of bug report.

If the current one is correct, then setting max_fps to 59 is the bug. Unless there is a good reason why it would show a much lower number.

This is the result in my PC with 59.95hz display.

On 59.95hz monitor.

max_fps	value
0	around 16.0ms
60	around 16.0ms
59	1.0 ~ 2.0 ms
55	1.0 ~ 2.0 ms
30	1.5 ~ 2.3 ms

Maybe I am not understanding this feature but with this result, what number does this Performance Monitor TIME_PROCESS supposed to show?

[AThousandShips]

But that's not what the performance measures, as it says, it doesn't say "the time it took to process in frame" or "time spent in _process", it shows as far as I can tell what it says it shows, "Time it took to complete one frame, in seconds."

Now for the specific clamped cases it is likely due to the behavior between syncing, can you test turning vsync off and on and see how it behaves?

[pegasusearl]

can you test turning vsync off and on and see how it behaves?

With VSync off, it shows (what I assume is) the number that I wanted to know, which is the correct process time. No matter what max_fps is set, time_process is always around 1.0~2.0ms

So the problem only happened with Vsync ON + max_fps set to 0 or >=display refresh rate, which is the default and what I prefer.

I wanted to know which one do you think the correct value? Is it 16.0ms or 1.0~2.0ms?
I really hope it's the 2 ms one, since the other number isn't particularly useful, we can already get the other number by dividing 1 second by the fps. Update: I added 3D scene and switching to iGPU, seems like the 2ms is not what I think it is.

[AThousandShips]

The correct value is the value between frames, which with Vsync is the frame time, i.e. 16 ms, that's how the engine does the frame processing, it actually describes the time between frames

This is also documented in a few places around vsync and fixed FPS, but should probably be mentioned here too, but I don't think this should be changed as it is useful data and does what it says

It should not be treated as "time taken to process things" as that's not what it is, and that's hard to measure, but can be a new performance monitor, I'd suggest a proposal

But changing this to not be the same as delta would be problematic (as they are documented to be the same thing, not actually exact value though), and we can't change the behavior of delta in this case AFAIK, so think the current behavior is correct and as expected, just needs some clarification

To be clear: The value comes from taking the time the whole of the step process takes in main, all processing for that frame combined