Add a V-Sync editor setting

[Calinou]

master version of #48366.

The editor setting makes it possible to tweak V-Sync status independently of the project setting.

Use cases:

• Decrease input lag and increase editor responsiveness when editing a project that has V-Sync enabled.
• Avoid tearing when editing a project that has V-Sync disabled.

Inspired by #20916, but the default behavior is now to have V-Sync enabled.

• See also Add a --vsync command line argument to control V-Sync status on startup godot-proposals#1923.
• This closes Stutter on Linux X11 when using multiple monitors #62821.

[Chaosus]

@Calinou Does this look actual after #48622?

[Calinou]

@Calinou Does this look actual after #48622?

Rebased and tested again, it works successfully.

[bjorn]

What's holding this up? I just spent a while trying to find a way to turn off V-Sync in the editor, until I found this PR. I'd love to get rid of the annoying input lag on Linux caused by the V-Sync!

After browsing the related issues, I noticed a comment about --disable-vsync, which actually does the trick for me. But an option in the Editor Settings would have been much easier to find. :-)

(And after trying this option, I have no idea why one would default vsync to on... the compositor seems to be already taking care of any tearing and the vsync seems to be just adding a huge unnecessary lag. Running X11 without compositor should be rather rare today, but maybe the behavior isn't the same everywhere...)

[Calinou]

What's holding this up?

It needs a review from a contributor who is knowledgeable in the area 🙂

I'd love to get rid of the annoying input lag on Linux caused by the V-Sync!

Right now, V-Sync in the editor is controlled by the V-Sync project setting. Since 4.0, you can also use the --disable-vsync command line argument when opening the editor directly on the project.

If you have a variable refresh rate monitor (and VRR is enabled on windowed applications¹), remember that you can leave V-Sync enabled and set a framerate cap by changing Low Processor Mode Sleep Usec in the editor settings to ceil(1.0 / vrr_fps_cap * 1000000), where vrr_fps_cap is determined by the formula refresh_rate - (int(refresh_rate / 60.0) + 1).

For instance, on a 60 Hz display, this is 58 FPS (17242 usec). On a 120 Hz display, this is 117 FPS (8548 usec), and on a 144 Hz display, this is 141 FPS (6945 usec). This allows you to get the best of both worlds (no tearing, low input lag).

See https://blurbusters.com/howto-low-lag-vsync-on/ for more information, and godotengine/godot-proposals#5451 which provides an automatic VRR-friendly framerate cap that can be selected by the user. (There's unfortunately no standard API to detect whether the user is currently using VRR, so this cannot be enabled automatically.)

(And after trying this option, I have no idea why one would default vsync to on...

I'd also prefer to have V-Sync off by default in the editor, but this should be discussed separately. reduz was against it last time I brought this up, since it results in noticeable tearing when panning in the 2D/3D editor viewports.

the compositor seems to be already taking care of any tearing and the vsync seems to be just adding a huge unnecessary lag

See also #71795. We don't know why this is occurring yet – input lag should not be higher than in 3.x in apples-to-apples comparisons. While disabling V-Sync will help a lot, we should still aim to resolve the original issue.

Edit: Input lag will be decreased once #80566 is merged too. This PR is still relevant nonetheless.

Footnotes

1. VRR is always enabled on windowed applications on X11 (if VRR is enabled in general), but VRR only affects fullscreen apps by default on Windows. ↩

[akien-mga]

Disabling V-Sync in the editor means burning CPU needlessly to render UI and the 2D/3D viewport, so this seems quite wasteful as a default setting. A lot of people use Godot on laptops and don't want to have fans spinning and the battery draining while organizing their scene nodes or writing scripts.

But adding an option to disable V-Sync is fine with me.

@Calinou This PR also needs an update to add the documentation, see CI checks.

[Calinou]

Disabling V-Sync in the editor means burning CPU needlessly to render UI and the 2D/3D viewport,

There's already a FPS cap in place in the form of low-processor mode, although it does not cater to the monitor refresh rate currently (it's roughly 145 FPS by default). See godotengine/godot-proposals#5451. In the long term, we should unify the low-processor mode sleep duration and max FPS project settings into a single setting, as they're redundant since 3.2 when the low processor mode sleeping was reworked to be smoother.

[bjorn]

Right now, V-Sync in the editor is controlled by the V-Sync project setting.

I had tried changing that setting but it had no effect, so I assumed it would only affect a running game or something. Now I realize the setting just needs a restart to apply.

Disabling V-Sync in the editor means burning CPU needlessly to render UI and the 2D/3D viewport, so this seems quite wasteful as a default setting.

I just compared CPU usage on my system and it's 1% regardless of V-Sync being on or off. Anyway, I can understand if the behavior is different elsewhere. (though, if we're really worried about CPU usage, then I would expect 0% usage when I'm not doing anything - and no animation is playing)

[Calinou]

@Calinou This PR also needs an update to add the documentation, see CI checks.

Done 🙂

(though, if we're really worried about CPU usage, then I would expect 0% usage when I'm not doing anything - and no animation is playing)

This is likely caused by the AudioServer running in the background when no sound is playing. See #63458.

[akien-mga]

Looks good overall.

How does this handle multiple windows? Do new windows spawned in the editor (e.g. dialogs) respect this setting too?

[Calinou]

How does this handle multiple windows? Do new windows spawned in the editor (e.g. dialogs) respect this setting too?

I'm not sure how to test this, as I don't have a working way of having a FPS overlay on individual Godot windows (MangoHud doesn't play well with self-compiled builds).

[akien-mga]

Thanks!