-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Major framerate drop on Windows when moving mouse in very simple project, unless profiling #60646
Comments
Apologies for not checking this from the beginning, but I just confirmed this also happens on v3.4.4.stable.official [419e713]. |
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. |
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. |
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. |
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. |
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. |
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. |
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 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.)
No. |
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. 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] 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) |
This comment has been minimized.
This comment has been minimized.
I'm having a similar issue, but I suspect that in my case it's a Windows bug. |
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.
Enabling |
I'd suggest updating to the latest Windows 11 version currently available (update |
@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. |
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. |
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. |
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. |
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. |
Thanks for the findings! Unfortunately, it seems we can't change MouseDataQueueSize just for Godot as it requires registry editing.
I have to remind you that we have a Code of Conduct. Please stay constructive. |
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: Here is a quick clip I recorded of this behavior, including the project file: 2024-02-26.19-04-39.mp4Running 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. |
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. |
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. |
Possibly relevant article: https://ph3at.github.io/posts/Windows-Input/ |
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:
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
The text was updated successfully, but these errors were encountered: