Godot 4 get_global_mouse_position() input lag with Forward+ renderer

[VilleMantyla]

Godot version

4.0.2

System information

Windows 10, GeForce GTX 1050 Ti

Issue description

The lag can easily be seen when moving a sprite with the mouse in _process()

extends Sprite2D
func _process(delta):
	position = get_global_mouse_position()

Steps to reproduce

2023-04-08.19-39-24.mp4

Minimal reproduction project

laggy_mouse.zip

[Calinou]

I can't reproduce this on 4.0.2 (Linux, GeForce RTX 4090 with NVIDIA 530.41.03).

This occurs because you have low FPS. Therefore, input lag is expected, especially since V-Sync is enabled by default in Godot. Disabling V-Sync in the project settings will reduce input lag, but it'll introduce tearing instead.

Note that video recording software can cause FPS drops on low-end (and even not-so-low-end) systems. Also, can you reproduce this issue when running the exported project with the editor closed? Can you reproduce this after switching to the Mobile rendering method or Compatibility (try both)?

[VilleMantyla]

Disabling V-Sync removes the lag completely. Running in Mobile rendering didn't change much, Compatibility improved the lag noticeably. Exporting the project with Forward+ changed nothing.

This issue occurred on my machine with this one particular project (i.e. a game I was making). Removed all the files and made the laggy_mouse.zip (posted above with the initial message). But as I tried to start fresh, only implementing the minimal scene and script, I could not reproduce the same behavior.

On a side note, I noticed that when my game window is not selected (the focus is on another window on Windows) there's no mouse lag, even with the initial setup. This is demonstrated in video below (at first the window is not selected, then I click on the window and the lag starts).

2023-04-08.21-05-58.mp4

[Calinou]

• Related to Major framerate drop on Windows when moving mouse in very simple project, unless profiling #60646 and Godot 4 editor UI (menus) significantly slower than 3.x #71795.

[darthLeviN]

I have the same problem here.
also, i have a 144Hz monitor but vsync locks in a 60fps.

i tried Input.use_accumulated_input = false but it didn't help with the input either.
keep in mind that with vsync disabled, 60fps work well. but with vsync enabled it will lead to big input delay.

[paskausks]

For my current project, this issue occurs as well, as well as the suggested changes to mitigate it:

Disabling V-Sync removes the lag completely. Running in Mobile rendering didn't change much, Compatibility improved the lag noticeably. Exporting the project with Forward+ changed nothing.

Windows 11, v4.1.stable.official [9704596]

[Calinou]

@VilleMantyla @darthLeviN @paskausks Can you reproduce this if you set Display > Window > Mode to Exclusive Fullscreen?

[paskausks]

@VilleMantyla @darthLeviN @paskausks Can you reproduce this if you set Display > Window > Mode to Exclusive Fullscreen?

Seems like the input lag is somewhat reduced (EDIT: although after some back and forth A/B, seems like its the same) on exclusive fullscreen, but its still there.

[mattdavisgames]

Hi, I just started using Godot with 4.1.1 and I'm experiencing this lag too.
Apologies for not having any neat captures or repro project yet. I can provide something more thorough if developers are interested, just wanted to roughly get my findings down first.

The same behaviour seems to be present in Forward+, Mobile and Compatibility rendering paths, and in Windowed, Fullscreen and Exclusive Fullscreen.
The following frame measurements were using Forward+, Fullscreen, using a 60fps recording on a 60Hz display.
I'm measuring latency between the Windows mouse cursor and the Godot object positioned at the cursor.

• VSYNC_ENABLED (default): 4 frames of latency, no judder.
• VSYNC_MAILBOX, uncapped framerate (about 200 fps): <1 frame (at 60Hz) latency. Minor judder. (The object is between cursor position of last frame and this frame.)
• VSYNC_MAILBOX, framerate capped at 180: <1 frame (at 60Hz) latency. Minor judder.
• VSYNC_MAILBOX, framerate capped at 60: 1 frame (at 60Hz) latency. Severe judder.

Here's the interesting part: using VSYNC_ENABLED and gradually increasing the CPU load until the framerate drops just under 60fps, the input latency drops to 1-2 frames, even though the framerate is lower.

I've never done any serious graphics programming, but this behaviour suggests that the problem is to do with Godot queuing too many frames in the swapchain when using vsync, leading to latency. When the CPU load increases, the GPU is forced to "use up" its queue of stored frames, reducing latency.

The issue may be less noticeable at framerates above 60, as 4 frames will take less time.

This vulkan page suggests that 2 "frames in flight" at once (https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Frames_in_flight) and searching the Godot source code for FRAME_LAG seems to suggest Godot implements this advice. But maybe something is bugged? I don't properly understand all of this, it's just a hunch that it has something to do with the swapchain.

(Using Windows 10, Intel i5-9300H CPU @ 2.40GHz, NVIDIA GTX 1650 Max-Q. Seems to be the same using integrated graphics or NVIDIA, though on my machine it seems to switch back to integrated automatically after a few seconds.)

EDIT: possibly the other source of lag is the forced use of triple buffering in vulkan_context.cpp:
uint32_t desiredNumOfSwapchainImages = 3;
I think that this, combined with FRAME_LAG = 2, could combine to create these 4 frames of lag. For a simple 2D game which pretty much any computer can run at the max refresh rate, it could make sense to be able to reduce these values to minimise input latency while keeping the consistent frame pacing and low power usage of vsync.

If I get a chance soon, I will learn to build the engine and test out this theory for myself.

[Calinou]

I've never done any serious graphics programming, but this behaviour suggests that the problem is to do with Godot queuing too many frames in the swapchain when using vsync, leading to latency.

Please test #80566, which aims to fix that issue 🙂

Note that the OpenGL (Compatibilty) issues you've mentioned are probably not fixed by that PR. A different solution is needed there, assuming you can't reproduce the issue in Godot 3.5.2.

[TempoLabGames]

I created a project to help measure this type of problem without needing a high speed camera, and I've just ported it to Godot. It's currently Windows only (sorry) but you may find it useful: https://github.com/TempoLabGames/UnityRenderingLatencyDemo

On my Windows machine using the Forward+ renderer with Godot 4.1.1:

WindowMode.Fullscreen, VSyncMode.Enabled: 2 frames
WindowMode.Fullscreen, VSyncMode.Disabled: 1 frame (no tearing)
WindowMode.ExclusiveFullscreen, VSyncMode.Enabled: 5 frames
WindowMode.ExclusiveFullscreen, VSyncMode.Disabled: 0 frames (tearing)

I'm not currently able to test #80566 as these build links don't work for me, but I'd be happy to provide results if someone can point me to an updated build.

[huezo89]

Same issue here where the game stutters if I move the mouse over the game's window (or fullscreen). Funny thing is I'm not calling any function related to the mouse, if I move the mouse outside of the game's windows, all is good, but as soon as I move the mouse into the game's window, the stutter begins.