Major framerate drop on Windows when moving mouse in very simple project, unless profiling

[Thoughtquake]

Godot version

v3.4.2.stable.official [45eaa2d]

System information

Windows 10, GLES 3, Geforce GTX 970, Core i7-4790, 32GB RAM

Issue description

The combination of the following observations leads me to believe there's a bug in the engine causing a severe performance drop when handling rapid mouse movement:

• With Vsync off, my game runs at over 1000FPS, regardless of mouse movement.
• With Vsync on, my game runs at 60FPS until I start rapidly moving the mouse - then FPS drops significantly, sometimes below 30FPS.
• When I enable profiling in the editor, the framerate drop no-longer occurs.

That last point is the most puzzling; I would expect profiling to slow things down, not speed them up.

I have stripped down my game project to a bare minimum repro; a Sprite node that follows mouse movement, and a label that reports the current FPS. I'm not sure what other details of my repro project may be relevant, as starting from a blank slate I was not immediately able to reproduce the problem.

I am not normally using Vsync via Compositor, but turning that option on makes the problem worse.

Note that I only see this issue on Windows; it does not happen on Mac or Linux.

Steps to reproduce

Unzip the attached project, open it in the Godot editor, and run. Then, rapidly move the mouse around inside the window.

Observed result: The label shows "60 FPS" when the mouse is still, and drops to lower numbers while the mouse is moving, at least as low as 31 FPS.

Minimal reproduction project

InputRepro.zip

[Thoughtquake]

Apologies for not checking this from the beginning, but I just confirmed this also happens on v3.4.4.stable.official [419e713].

[Calinou]

Are you using a variable refresh rate monitor (G-Sync/FreeSync)?

[Thoughtquake]

Are you using a variable refresh rate monitor (G-Sync/FreeSync)?

Nope. Unfortunately I don't have a variable refresh rate monitor to test this on.

[Thoughtquake]

Update: I can reproduce this with an even simpler project, attached. This time I started from a new project and didn't change any project settings, and I removed the Sprite node that was following the pointer. At this point there are no _input methods anywhere, and the only script is to display the current FPS in a label. There are only two nodes in the scene.

The framerate drop when moving the mouse isn't as bad as before, but it gets as low as 43FPS if I continue rapid movements.

InputRepro3.zip

[Thoughtquake]

I have now tried this on another PC which does not reproduce the issue. However, I can't imagine it's related to the performance of the hardware - both PCs can handle games like GTA 5 well. Also, that wouldn't explain the problem going away while profiling in the Godot editor.

[Calinou]

I have now tried this on another PC which does not reproduce the issue. However, I can't imagine it's related to the performance of the hardware - both PCs can handle games like GTA 5 well. Also, that wouldn't explain the problem going away while profiling in the Godot editor.

This hints at the performance bottleneck being linked to higher mouse USB polling rates (500 Hz or 1000 Hz). See also #55037.

[Thoughtquake]

I can confirm I'm using a mouse with a 1,000Hz polling rate, on both machines. Not seeing this on the second machine might be a fluke; the framerate drops do mysteriously stop happening sometimes, but they always come back eventually. It seems I'm unable to reproduce it within a short time of booting.

FYI, I can reproduce this at least as far back as Godot 3.1.

[Thoughtquake]

I might be onto something - I couldn't reproduce large framerate drops until I put my PC to sleep and woke it back up. I do that often enough that a sleep/wake may have happened before every other occurrence.

Based on one of the related issues I tried calling this in _ready: Input.set_use_accumulated_input(true)

It didn't help.

[Thoughtquake]

This is a pretty serious problem for my game - on another machine the frame drops as low as 1FPS when moving a mouse with a high polling rate. Lowering the polling rate fixes the problem, but I don't expect most players to know how to do this.

Again, using accumulated input doesn't help (even on Godot 3.5 RC6), but starting profiling in the editor does. How is that possible? Does the profiler somehow separate the input handling from the rendering thread?

I've been hoping to spot the cause myself using profiling tools, but the CPU usage is negligible even during the extreme framerate drops.

[Calinou]

I've never been able to reproduce this on any of the machines I have access to (with a 1000 Hz mouse), so I'm afraid I can't do anything about this. Limiting the rate at which _input() can run may help (e.g. by calling set_process_input(false) for a certain duration of time after _input() was called once, then set it to true again).

Given the issue only seems to occur with V-Sync enabled, you can also try disabling V-Sync and cap the FPS to the monitor refresh rate to avoid the issue. (You can also try capping the FPS to the double of the monitor refresh rate to further decrease input lag and improve overall smoothness.)

Does the profiler somehow separate the input handling from the rendering thread?

No.

[distantforest1]

I just want to add my 2c, I'm also getting this issue. I'm using a G203 Lightsync mouse with 3200 DPI at 1000hz. Setting it to 500hz makes it a bit better, but it still spikes alot when moving the mouse.

Tested with the various V-Sync settings (Off, On, Mailbox, Adaptive), it still spikes.
Tested with Release build, still spikes.

The spikes happen only in Windowed mode for me. (Which happen to be what I game in 99% of the time)

Godot v4.0.2.stable.mono.official [7a0977c]
Windows 10 Home 64-Bit
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 531.68
AMD Ryzen 9 3900x 12-Core Processor ~3.8GHz
32714MB RAM

I'm using a pretty beefy machine, so cpu shouldn't be an issue. Also tested on other game engines and mouse movement doesn't lag. (Unity Release build, Love2D)

[rune-scape]

Godot v4.0.2.stable.mono.official [https://github.com/godotengine/godot/commit/7a0977ce2c558fe6219f0a14f8bd4d05aea8f019]
Microsoft Windows 10 Pro
NVIDIA GeForce GTX 1080 Ti
AMD Ryzen 5 3600X 6-Core Processor, 3793 Mhz, 6 Core(s), 12 Logical Processor(s)
also getting this issue, i tested with g-sync on and off, and it didn't seem to make a difference in fps drop

using an empty project with just a control node on Forward+ renderer:
with my mouse at 1000Hz polling rate, my fps dropped to exactly 1 when wiggling

changing my polling rate from 1000Hz to 500Hz instantly made the problem mostly go away, but it still dropped from ~2000fps to ~500fps

[univeous]

I'm having a similar issue, but I suspect that in my case it's a Windows bug.
After the computer woke from sleep, all windowed games, not only Godot but Unity or GameMaker games, experience extreme frame rate drops (8~20fps) when shaking the mouse quickly.
A reboot can fix this but I'm still wondering why🤔

[Swarkin]

Using v4.1.stable.official now, this issue happens for me on every new project I create and is definitely related to high polling rate mouses. Godot doesn't seem to handle 1k mouse updates per second well.
I have found out that this issue completely disappears once the mouse is captured:

func _ready():
	Input.mouse_mode = Input.MOUSE_MODE_CAPTURED

Enabling Input.use_accumulated_input does not fix it for me.

[Calinou]

I'd suggest updating to the latest Windows 11 version currently available (update KB5028185), as noted in this article.

[Swarkin]

@Calinou What about people using Windows 10 tho? I'm not sure if this update will appear there..

[Calinou]

@Calinou What about people using Windows 10 tho? I'm not sure if this update will appear there..

It's unlikely to be backported, as Windows 10 mainly gets security fixes nowadays (until 2025).

In general, if you're running a system for gaming and other high-end use cases, I'd recommend upgrading to Windows 11 or switching to Linux. Windows 10 is not going to be supported forever 🙂

Many features that are interesting for gaming such as Auto HDR are also only available on Windows 11.

[Thoughtquake]

I'd recommend upgrading to Windows 11 or switching to Linux.

That's fine advice for end users, but as a developer I want my game to work well on all supported operating systems. Also, many very capable gaming PCs are not supported by Windows 11 due to TPM requirements, so I think there will be more hold-outs than usual for upgrading.

[Calinou]

Also, many very capable gaming PCs are not supported by Windows 11 due to TPM requirements, so I think there will be more hold-outs than usual for upgrading.

It is possible to bypass the TPM/CPU requirements when installing Windows 11. For example, Rufus can do it for you by just enabling a checkbox when creating a bootable USB drive.

[Harris170]

Happend on latest Godot Engine v4.1.1.stable.official.bd6af8e0e on windows 10, and the framerate drop was fixed when i rebooted my PC.

[okbuss]

Hi, from my findings, this bug is related to windows MouseDataQueueSize - aswell as mice with high polling rates. If your MouseDataQueueSize is high, then windows tries to optimize mouse inputs my accumulating small movements and outputting them as one. If you have a low MouseDataQueueSize, windows is forced to output every little mouse movement without optimizing them, great for hardcore vidya gamers, but this is too much for unoptimized godot xDD

In my case at least, setting MouseDataQueueSize to 105 fixed a lot of the fps drops, now i only get around -5% fps when moving the mouse in an empty project, and i'd probably get more if i set the MouseDataQueueSize higher (But rip mouse accuracy lol)

Either way, from the way people reacted on my reddit post about this issue (/r/godot/comments/18cemvb), and from the time that this post has been up, i seriously doubt any godot developers will fix this let alone even mention that there engine buckles it's knees when faced with lots of mouse input. The only way seems to be to just keep complaining and maybe in some years they'll do something about how their engine handles massive amounts of mouse input, because even in unity or unreal, i can happily have an absurdly low MouseDataQueueSize and use my 1000hz mouse without any problems.
I literally just wanted to make a game, but this bug has basically stalled my project and burnt my head, and it makes me scared to get too invested into godot in fear that i might find more issues that won't be fixed, and then i would've wasted my time.

[Calinou]

Thanks for the findings!

Unfortunately, it seems we can't change MouseDataQueueSize just for Godot as it requires registry editing.

Either way, from the way people reacted on my reddit post about this issue (/r/godot/comments/18cemvb), and from the time that this post has been up, i seriously doubt any godot developers will fix this let alone even mention that there engine buckles it's knees when faced with lots of mouse input. The only way seems to be to just keep complaining and maybe in some years they'll do something about how their engine handles massive amounts of mouse input, because even in unity or unreal, i can happily have an absurdly low MouseDataQueueSize and use my 1000hz mouse without any problems.

I have to remind you that we have a Code of Conduct. Please stay constructive.

[wmboeckman]

Thought I would add a little bit to this. Not only do I experience this very issue with high polling rate mice (I use a Razer Viper 8k, so I can cause the entire project to hang completely if i circle the mouse fast enough lol)

In my (limited) testing, it seems like the way Godot handles mouse input (in Windows) seems to cause a pretty big difference in FPS in an empty project.

With V-Sync off, with the game window not in focus (and therefore not processing things like mouse input) I get somewhere between 1k-220 fps, with very strange fluctuation. However, when the window is brought into focus, I drop down to only 100-112 fps.

I'm on Godot v4.2, running Windows 11 Version 22H2, Updated to KB5034765.

On older hardware, but still enough to get more frames than shown:
Intel Core i7 6700k, 2x8GB RAM@2500, GTX 1080 w/ 8GB vRAM

Here is a quick clip I recorded of this behavior, including the project file:

2024-02-26.19-04-39.mp4

Godot Mouse Polling Bug.zip

Running on relatively older hardware, but I should be experiencing higher frames than this, no?

Also, the same effect can be seen on the actual editor window. For example, if you have the profiler open for a running project and move the editor window with a high polling mouse, the profiler will hang!

Really hope this gets prioritized, sure I can use a lower polling rate and be just fine, but anyone else who plays a game I make will have to do the same :/

[wmboeckman]

Thought I would add a little bit to this. Not only do I experience this very issue with high polling rate mice (I use a Razer Viper 8k, so I can cause the entire project to hang completely if i circle the mouse fast enough lol)

In my (limited) testing, it seems like the way Godot handles mouse input (in Windows) seems to cause a pretty big difference in FPS in an empty project.

With V-Sync off, with the game window not in focus (and therefore not processing things like mouse input) I get somewhere between 1k-220 fps, with very strange fluctuation. However, when the window is brought into focus, I drop down to only 100-112 fps.

I'm on Godot v4.2, running Windows 11 Version 22H2, Updated to KB5034765.

On older hardware, but still enough to get more frames than shown: Intel Core i7 6700k, 2x8GB RAM@2500, GTX 1080 w/ 8GB vRAM

Here is a quick clip I recorded of this behavior, including the project file:
2024-02-26.19-04-39.mp4

Godot Mouse Polling Bug.zip

Running on relatively older hardware, but I should be experiencing higher frames than this, no?

Also, the same effect can be seen on the actual editor window. For example, if you have the profiler open for a running project and move the editor window with a high polling mouse, the profiler will hang!

Really hope this gets prioritized, sure I can use a lower polling rate and be just fine, but anyone else who plays a game I make will have to do the same :/

Quick update, the weird frame limiting I was experiencing was due to a graphics driver issue, needed a clean install that must have overwritten a bad setting on my end.

Still experience the mouse polling issue, unfortunately.

[Swarkin]

The severity that you show in your video at 8000hz happens for me at 1000hz already. I'm running pretty good hardware; overclocked intel i5-9600k and a rx 6700 xt if that matters.

[jitspoe]

Just wanted to note that I'm also seeing this issue in Godot 4.3. I had a test project that was getting over 1000 fps, and when moving the mouse over the window, the framerate halved into the 500's. If I move the mouse around outside of the window, over the Godot editor, the framerate stays over 900. However, if I have a different window in the background, such as a web browser, the framerate drops more.

I thought maybe it was some issue with windows drawing the cursor over the window, so I changed the mouse_mode to Input.MOUSE_MODE_CONFINED_HIDDEN and still had the issue.

Also, it seems it's still causing like a 10% framerate hit on lower framerate projects. I've got one where I'm getting about 75-80, and when moving the mouse outside the window, it doesn't seem to impact the framerate much, but inside the window, I get 68-73 FPS.

I was using this project to test: https://github.com/godotengine/godot/files/14203338/test_omnilight_fade.zip

Note that you can enable/disable the omni lights to change the perf.

Also note that I'm not doing ANY input handling in the script. Just displaying the FPS.

[Calinou]

Possibly relevant article: https://ph3at.github.io/posts/Windows-Input/