I’m surprised people are only noticing this on Big Sur, since I’ve been seeing this as early as Mojave using a 1kHz ‘gaming’ mouse. (It may have happened in even earlier versions of the OS and is just getting progressively worse on every new macOS release…)
I suspect this is at least part of the reason why some people have mysterious performance problems with VirtualBox on macOS[0]—at least, it’s how I first noticed the problem. (I’m sure VirtualBox has some other issue going on too, since its event queue gets backed up so badly that even keyboard events become delayed. Life gets interesting when the delays are so long that the guest OS key repeat is triggered!)
Does anyone know of some small utility that adjusts mouse polling rates to at least mitigate the issue? The official Logitech software to do this is 476MB, 5 kernel extensions, and a launch daemon, which is a bit much just to send a USB command.
What if you used something like Synergy so that the mouse and keyboard input is shared over networking between host and guest rather than the virtual USB interface?
I've been writing some UI widgets, and I bet this is caused by redrawing the widgets every time the mouse moves. I've not used Big Sur so I don't know if this is the case, but if they added highlights on mouseover, the easy way to make that work is redraw on every mouse move, just in case the mouse entered or exited a control. The slightly harder way, of course, is to detect transitions and only redraw then.
I also remember wiggling the mouse to get installation programs to progress.
Sometimes it would be stuck at 100% for ages, as usually you're not interacting with the machine during an install, and then somebody would wiggle the mouse and suddenly 'Installation complete'
You'd think an end user computer HW+OS by now would decouple the UI at a hardware level and figure out how to minimize the performance losses from at least a two-tier design. But, this would require new ground up everything, including new end-user software dev paradigms, and by-design potentially second-tier performance in order to maximize security. This seems insurmountable, of course, but I bet such innovations will emerge this decade.
My money is on whoever can offer fundamental, fully integrated fixes to the whole stack from cloud to edge. Jumpy cursor CPU's, and monolithic internet/endpoints will be an anachronism.
Kudos to Apple for being performance leaders, though. I just find the current assortment of consumer hardware offers weak assurances by default (not everyone has a megacorp or resources to harden and protect their infra). This small mouse cursor bug reminds me of the rabbit hole that needs fixing, imo.
Acorn (early ARM personal computers) had a hardware sprite mouse cursor; because moving the mouse in software was expensive.
A fun thing is you can have a monochrome graphics mode and the mouse cursor will still be blue.
>Finally, I tried and with a Magic Trackpad 2 (which should have a polling rate of ~90Hz) and with the built-in MacBook trackpad, and there were almost no changes to the WindowServer CPU usage.
I just decided to test it on my MBP, continuously moving the cursor on trackpad, WindowsServer was hovering at ~20+%, and 2-5% when it is not moving. It is not as high as an USB mouse but it is definitely problematic.
And I have noticed this for quite some time, I just never thought it was the mouse / cursor.
Up until some version I could kill the acceleration curve with SteerMouse (but not the scroll acceleration), but there was still the 2 frame lag. It's also extremely distracting how you can see the UI further lagging behind the cursor when you drag windows or click buttons. Another frame or two of delay, bringing it to a total of 64ms.
I have a 1000km RTT ping that takes less than it takes MacOS to react to mouse movement. It feels like using a remote desktop.
After Big Sur, the issue got even worse, especially on external displays. CPU usage also spiked through the roof.
After developing for a while on a Windows machine with a 144hz display and a 500+hz mouse I can't go back to using MacOS. It feels like trying to use a car infotainment system by comparison.
I also couldn't get a 2019 15" MBP to work on the external display at over 100hz using DP Alt Mode over a HDMI2.0 cable. The same one works fine on my desktop or on a ThinkPad.
Sounds like they’re working on removing the 60fps hard limit that macOS has had for the past fifteen years, as part of bringing 120Hz support from the TV and tablet line to pro Macs someday.
I was thinking of the hard limit on Apple's monitors, which have always been locked at 60Hz (such as MacBook, iMac, and Pro Retina). But I'm glad to hear that macOS is ready, even if the hardware isn't! Thanks for the correction.
I recently learned that moving my mouse was causing the coil whine sound coming from my Win10 gaming PC. Turning down the polling rate on my mouse was the only fix that worked.
I started getting coil whine yesterday, after adjusting my fan curves. Not really sure why, but with the fans off the whine was far louder than keeping them on a low-speed minimum. It’s not fan noise blocking out the coil whine, because I still can’t hear the fans (they’re Noctua’s). I don’t know if it’s due to thermals, something to do with the power load, or what.
I’ll have to look at the polling rate thing, too - thanks for the tip.
I've also been hearing coil whine sound coming from MacBook's Caldigit dock when using a wired gaming mouse (only in totally silent rooms).
I haven’t mentioned it in the article, but just like you said, lowering the polling rate fixes it too.
Same issue here on a MSI laptop, the weirdest thing is that the coil whine is louder when opening certain applications like the desktop client of Signal and HoneyView image viewer.
Events just get put into a queue, and somewhere in the guts of the application there will be a loop that does:
while (stillRunning) {
event = getEventOrWait();
// handle event
}
(In macOS this is done inside [NSApp run], but Windows and Linux make the loop explicit.)
I think the 1000 Hz you are thinking of is the accuracy of the UI timers. Since you're just calling this in a loop, not waiting for a timer to fire, you can burn through a lot of events in one timeslice. And since most systems have multiple processors, it is reasonable for your game to be running continually, especially since modern OSes frequently prioritize certain kinds of programs (and a game might request prioritization if at all possible).
I suspect this is at least part of the reason why some people have mysterious performance problems with VirtualBox on macOS[0]—at least, it’s how I first noticed the problem. (I’m sure VirtualBox has some other issue going on too, since its event queue gets backed up so badly that even keyboard events become delayed. Life gets interesting when the delays are so long that the guest OS key repeat is triggered!)
Does anyone know of some small utility that adjusts mouse polling rates to at least mitigate the issue? The official Logitech software to do this is 476MB, 5 kernel extensions, and a launch daemon, which is a bit much just to send a USB command.
[0] https://www.virtualbox.org/ticket/16436