Hacker News Reader

Comment by ndiddy | Hacker News Reader

I’d prefer not to have my mouse stutter because the driver paused to run the garbage collector.

Mouse stutter has become more common in Windows. Every time I open a web page with Spotify embed mouse freezes for ~0.5 to 1 second and then continues moving, I haven't found any reason for it, it happens with Firefox, Google Chrome, and Edge.

It's been repeatable ever since I bought a Ryzen 7950X at the beginning of the year, that's why I tried using system profiler tools to find the reason but as I have no good experience in this it's difficult to find the root cause.

I had similar problems maybe 15 years ago, so I don't remember exactly how I solved it. In my case it was a NIC driver that filled up some queue when I downloaded "Linux ISOs" too fast over bittorrent.

There are tools available to find the source of the problems, I think I used event tracing as a starting point.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Unplug and try a different mouse. Unplug and disconnect any other peripherals except the mouse and try that. Try a new user on windows (user space apps) Try a fresh install (system stuff) If you have spinning rust try another hard drive (an app doing stupid blocking exclusive stuff with writing or reading can pause input stuff).

Did you do any overclocking (especially RAM)? I've seen issues like this with either slightly unstable OC, or bad drivers.

I'd also suggest running https://www.resplendence.com/latencymon to see if it's a specific driver causing the stalls, or if it's random.

I noticed it after I upgraded to a 3900X. Not sure if it's an AMD thing, a USB hub thing, or a many-core thing. But it had never happened before. (Microsoft Pro Intellimouse)

It's probably an AMD thing. I had the same with a 5800x until I switched to a PCIe/usb card instead of the onboard ports.

You can use UI4ETW[0] to capture an event trace when the mouse freezes. You may need to install the Windows SDK or Visual Studio to interpret the results, though.

[0] https://github.com/google/UIforETW

Days of lag-free mice are well and truly over...

(Sitting here running wayland, where the mouse feels stuck in molasses!)

(Sitting here running Wayland aswell, where the mouse feels just fine)

I wish I had a problem with mouse on Wayland, but it doesn't run for me at all

(Sat here using KDE Plasma on Wayland where the mouse lagged and glitched every time you opened a program.)

I think later versions fixed this one, though.

That's not a Wayland issue. It may be a specific Wayland bug that affects you, but the architecture of the system does not force any extra delays.

Imagine we are half way through sending a frame to the display.

The cursor is in the bottom half of the screen.

If I move the cursor, that should be represented in the frame that's being currently outputted, not the next frame.

Wayland has no support for that, by design.

The end result is that there is always a delay of at least one Frame.

There are ways to solve that and it’s not an architectural flaw. You just need prediction in the compositor to adjust the location of the mouse.

But honestly, the difference of a frame of latency is ridiculously difficult to feel and we’re talking about a half frame of latency here on average. It’s almost likely something else considering the entire end to end latency here is closer to 50-100ms on most systems and still isn’t what people would describe as laggy. Usually it’s some kind of software bug/hiccup that interrupts things to not be rendered at a constant tick rate or just getting hung and not processing events in a timely fashion.

There's a big difference between slow as molasses and one frame of 16ms (which you sacrifice in exchange for no screen tearing). Unless you're really into high rank competitive shooters, I doubt you can even tell that 1 frame delay is happening.

Also, make sure you use the right config - there are actual issues with some competitors which are not Wayland architecture issues. For example https://github.com/swaywm/sway/issues/4763

Check your display refresh rate. I had issues on Linux with it not supporting the maximum HDMI bandwidth properly so it drops the refresh rate to 30Hz which makes mice super laggy.

Might be worth it to check that you have the "Adaptive" acceleration profile with a positive pointer acceleration value set in your mouse settings.

Which compositor are you using?

If it's Gnome, the very recent release 45 has improvements running the cursor in a separate thread.

I personally run KDE and agree that you can feel a difference between the X11 and Wayland session but it's not terrible.

As opposed to a stall induced by reference counting?

Don't allocate => don't need to collect.

It's not that hard to write no-alloc C# code. Happens in Unity dev all the time.

It's not, no. But it's also very easy to write alloc C# code and people will if you give them the option. That won't be possible in Rust / C.

Even so 16.666 ms is a lot of time for just handling mouse input.

The CPU has other things to do too.

No matter what you do the CPU will always have other stuff to do.

So you agree...

Attitudes like these is how we eventually end up with bloated messes like Electron. Performance matters, everywhere. Some of us increasingly also use monitors with more than 60 hertz.

Yes. 640 usec should be enough for every mouse.

It's also very easy to write alloc C++ code, no?

This is pretty silly. They have the option to alloc and leak in C too. Rust is also just guaranteed memory safety not leak free, right? In a competition of lazy code, I'd rather GC pauses than OOM crashes.

But C# isn't ideal for a driver because of the weight of the runtime not because it's hard to save on allocations.

It is correct that Rust does not (nor claim to) solve memory leaks.

Reply on news.ycombinator.com