In the past a lot of people have made the observation that using a mouse with a high polling rate (usually >1000 Hz) can lead to loss in frames per second both in the editor and builds.
See the following links:
Some of the reported bugs seem to have a resolution, but after testing the “fixed” engine versions on my own I observe that none have the issue fixed in any way and still have performance issues. In e.g. the latest LTS version 2022.3.43f1 the frame rate even drops to zero in builds, when the mouse is moved fast enough.
Does somebody currently use/know a version that works without any problems?
Can you provide more information about your hardware (computer and mouse) and OS version? Thanks
Sure, I’m using the “ENDGAME GEAR OP1 8k” mouse on Windows 11 Pro 64bit (Version 23H2, OS build 22631.3880) for testing.
CPU: AMD Ryzen 5 3600 6-Core Processor 3.95 GHz
GPU: NVIDIA GeForce RTX 3070 Ti (Driver Version 32.0.15.6081)
Having the same problem here with Unity 6000.0.19f1 with a Razer Deathadder V2 set to a polling rate of 1000hz on Windows 10 Pro 22H2, Build 19045.4894. There’s a noticeable decrease in FPS even at 500hz. Don’t notice much drop if any when the mouse is set to 125hz. Happens in both the editor and in builds.
My specs:
CPU: AMD Ryzen 5800X3D
GPU: NVIDIA RTX 4080 Super
Still happening?
I also got fps dropped when moving mouse very fast
yes, still happening (tested with 6000.2.1f1)
Still happening in Unity 6.2.
Not happening in other games.
And it’s happening in windows build
Yup…still happening. I just set a profile on my mouse to set the polling rate to 125hz when I’m using the Unity editor. The builds are a problem though since so many people use gaming mice now…
This should have been fixed a good while back. Can anyone running into the issue show what the profiler shows for your affected game? What input system package version are you using?
I’ll provide my profiler for both editor and a Windows development build for a completely fresh URP project on an empty scene. Both are on the latest 1.15.0 input system package.
For the editor, rapidly moving my Razer DeathAdder V2 @ 1000hz polling rate:
It’s very apparent where I start moving my mouse. Even with deep profiling, I can’t see anything since it’s all contained in the EditorLoop.
For build, I’m seeing a huge increase in average frame times when I move my mouse in the PlayerLoop, dropping from 700FPS to around 400FPS without deep profiling turned on:
Nothing that stands out in the hierarchy though when looking at one of the spikes (12.15ms in PlayerLoop). Deep profiling didn’t yield anything too interesting, except that when I rapidly move the mouse, I get this:
I’m thinking something from the input side is generating so many events, it overwhelms the profiler’s buffer when deep profiling is turned on…
For reference, this is what it looks like when I’m not moving my mouse (the large lime green spike is from me ALT+F4ing out of the build):
When not moving the mouse in the build, the profiler scale starts at 0.1ms with frame times around 1-2ms mostly from rendering, whereas when moving my mouse (second screenshot), the scale starts at 5ms, with even the lower frame times starting at around double the amount of what it’s at when not moving the mouse.
So yeah, the issue is definitely still here.
You should not need to use deep profiler. For the editor screenshot, you can switch the profiler to “editor” mode instead of “playmode” (as seen in your screenshot) - that might show what the editor is spending time on.
I’d say drop from 700 fps to 400 fps when you start generating input events isn’t that unexpected - that means going from 1.4 ms per frame to 2.5 ms per frame. That said, that 12 ms spike is not expected.
For the player, I think we will need to go a bit deeper as it seems to be spending time where Unity’s profiler cannot see. Would you be willing to record me a trace of the runtime doing this using Windows Performance Analyzer (select CPU usage) - guide here: Recording a trace on PC
Learned something new today! Here’s the profiler in the Editor with it switched to Editor mode on a frame where I moved my mouse rapidly:
And yes, I can record you a trace. Here’s a screenshot of what I got:
I had some weird behavior while taking this trace. Instead of dipping to 400 FPS, it went all the way down to 30 FPS or even single digits in brief instances. You can see the parts where I’m shaking my mouse from the CPU spikes. I’ll DM you a Google Drive link to the trace as it’s too big to share here.
Thanks for the recorded trace. It revealed some bizarre interactions on your system but it is missing some key piece of information so I cannot see the culprit. Could you record me another trace, using this CPU+DotNet+DXGI.zip profile? You can uncheck all other checkboxes in Windows Performance Recorder.
You can also significantly reduce the size of the resulting trace by exiting irrelevant programs for the duration of recording - I noticed the main contributors to trace size (apart from the built runtime process) are the Unity Editor, TranslucentTB.exe and PowerToys.AlwaysOnTop.exe.
I’ve DM’d you a new trace with that profile. I’ve exited out of most programs for this one, and performance seemed more steady than yesterday, dropping about 10-15% when I moved my mouse. When I went to check the editor, frame time went from about 1.7-2ms to about 4-5ms in play mode when moving my mouse, which was slightly more usable than usual. Most likely one of the programs was further exacerbating the underlying problem, making it more visible for me.
EDIT: I restarted my computer to have all my regular programs open, and the results are similar for the Player, about 10-15% drop (from ~270FPS to ~230FPS) when I move my mouse. Editor play mode was noticeably worse though, going up to 30ms now. I did some testing, and it seems TranslucentTB was the culprit for hugely worse performance. After closing it, the frame time increase was about 2-3x from the baseline 1.7-2ms in play mode when moving my mouse for the editor.
From what I can tell in the trace, most of the overhead in that 10-15% is coming from deep profiling. Did you leave that enabled by any chance?
I also see that about 2.6% of the time is spent waiting on the system locks when retrieving mouse input events. On Windows, the input buffer is a global resource and is protected with a global lock, so if multiple processes are listening to mouse events, each has to wait for others to finish before being able to continue. This is how that 2.6% is broken up:
1.5% - nvidia graphics drivers
0.44% - windows internal machinery
0.28% - Rainmeter.exe
0.17% - RTSSHooks64.dll (this gets injected into the game process on your machine)
From what I’m seeing in this trace, I really don’t see any issues inside the Unity runtime. All the overhead is coming either from deep profiling, or other software running on your machine (which explains why we weren’t able to reproduce these issues internally). But if you produce another trace without deep profiling, I would be happy to look at it. Here’s a new trace file that would give me even more information than the last one: CPU+DotNet+DXGI.zip.
I suspect that the performance drop in the editor going from 2 ms to 5 ms could be explained by the fact that moving the mouse also makes other panels (other than game window) repaint. We’d consider this overhead acceptable. If it ever grows to levels where it would cause you to miss VSyncs (like the numbers you reported in initial posts), that is something that we would want to fix.
Yup, my bad. I’ve recorded a new trace with the new profile you sent over on a dev build with deep profiling disabled. On this new trace, I’m seeing FPS go from ~1400 to ~800 when moving the mouse. Editor performance also seems worse today when moving the mouse with the same applications opened as the trace, with frame times going up to 100ms even with what I thought was the culprit (TranslucentTB.exe) closed. I did notice that when I move the mouse off of the Unity Editor window, the frame times do not get affected. The moment I do it in any part of the Unity Editor, then the frame times increase dramatically, so the panel repainting might be the reason. It makes the editor unusable in play mode when frame times go up this high though.
EDIT: I think I found the culprit for the insanely worse editor performance. It was Discord of all things. The moment I closed it, the frame times capped out at ~10ms when moving the mouse @ 1000hz. With it opened, it was instantly worse.
EDIT2: Closing even more apps until there was barely anything open, I managed to get acceptable editor performance (~3-5ms of frame time). Not really feasible for me to close everything every time I want to work in Unity, though.
I still have to look at your trace, but do you by any chance have Discord Overlay enabled? That will cause Discord to inject itself into every panel in the editor, and since the editor usually has about 10-15 of them open at the same time, it can cause perf issues.
Nope, I disabled it a long time ago after it caused some performance issues in some games.
Apologies for the delay. It is unfortunately as I feared. I can clearly see the framerate spikes, and some frames suddenly taking 10-12 ms when you move your mouse (even if the overall framerate remains high).
I looked at a few of these in the trace and they all look like this:
It shows that the game process isn’t doing any work, but rather waiting for something.
Doing wait analysis, I can see that it’s waiting for a plethora of other processes (look at the Waits (μs) column):
In essence, these processes are also listening to mouse messages, and since it’s a shared resource, them holding the resource locks prevents Unity from continuing with the frame until input processing is done.
I understand that it’s not the answer you’ve been looking for, but I don’t think we can reasonably do anything about it. It is not our code that is delaying input queue on the system - we’re a victim in this scenario.
