**Godot version:**
3.0-beta2, but goes back to 2.1 at least
**OS/device incl…uding version:**
Linux x64, Ubuntu 16.04.3 LTS
Nvidia driver 384.90, GeForce GTX 970
**Issue description:**
Not exactly a duplicate of #10388, but the identical situation with a worse result. The conditions are:
- Render framerate(monitor refresh rate if vsync is enabled and conditions are ideal) and physics framerate are almost, but not exactly, equal
- The measured render frame time fluctuates
The issue is the simple `while (time_accum > frame_slice) {`-loop in Main::iteration() that determines the physics updates. Usually, if the two framerates are almost equal, the loop runs exactly once because the comparison yields stable results every frame. But over time, due to the slight framerate difference, time_accum at the start of the update drifts upwards or downwards. When it drifts close to 0 or frame_slice, the loop won't run at all or twice. If that only happened once, that would be fine, but unfortunately, then the variable measured frame time comes into play and the loop comparison becomes unstable from frame to frame, leading to many subsequent render frames with fluctuating numbers of physics updates (0, 1 and 2 if the monitor refresh rate is higher than the physics refresh, 1, 2 and 3 if it is lower). That looks ugly for a bit. The countermeasures discussed in #10388 do help here, too, but I think we can do better by default.
**Steps to reproduce:**
Make sure your monitor refresh are only a tiny bit different (setting the physics update to 59 or 61 in project settings is too much). Run the attached project for a bit. It measures recent max and min number of physics steps per render frame. It also shoots a string of bullets that move a bit down on every _process() and a bit to the right on every _physics_process(), making differences between them visible as the stream becomes jaggy. Obviously nothing anyone would do in a real project.
The test project also shows the recent max and min render frame times so you can see the fluctuation.
The ideal display when the two rates are exactly equal is this:
The stream is a nice diagonal line, min and max physics steps are both 1. However, sometimes (for me, once or twice a minute), the display changes and shows this:
The physics update cadence is something like 1, 1, 1, 0, 2, 1, 0, 2, 0, 2, 0, 1, 1, 1, 1, physics frames per render frame, it can extend for much longer than that. For me, with a refresh rate slightly above 60, the min and max updates are 0 and 2; for someone with a slightly lower refresh rate, they would be 1 and 3.
Now, one total dropped physics frame is of course inevitable if you insist on correct timing in your game, but it should look like this:
I implemented a primitive first fix attempt here: https://github.com/zmanuel/godot/commit/90a11efc0b27c1128d8203a9be8562fcde006867, the last screenshot was taken with that fix.
The idea of the fix is to simply add some hysteresis that makes the updater choose physics update iteration counts close to the one from the last frame.
The fix does not handle the case where the physics update is 30 fps and the display refresh is close to 60 Hz (or, more relevant to the hardcore, the physics update is 60 fps and the monitor has close to 120 Hz):
If there is demand, I can extend the fix to that situation. It would simply not just stabilize the render frame to render frame fluctuations, but fluctuations over groups of render frames. Probably requires a helper class for clarity.
**Minimal reproduction project:**
[timer_test.zip](https://github.com/godotengine/godot/files/1598840/timer_test.zip)
- [x] I searched the existing [GitHub issues](https://github.com/godotengine/godot/issues?utf8=%E2%9C%93&q=is%3Aissue+) for potential duplicates.
