Dealing with mouse drifting while in motion, at wits end.

[sqwash]

So this could be interesting, from what I can tell when using the Mousetester app my feelings regarding 1000hz polling might be right?

 

Remember I said that even when my mouse functioned correctly 1k polling didn't feel right (almost like there was added drag on the Y axis only) and that I always preferred high sens with 250/500 polling. Well, I swapped mice out recently from the 8k viper, for 2 reasons. 1, I keep hitting the ambidextrous thumb mouse buttons by accident and also because the polling range is limited from 125, 500 and 1k+ etc.. 500 felt the best, while (when it didn't cause camera panning stutters) 8k looked the best. In the regard that it translated well into my 240hz monitor and appeared to make panning and frames present like butter. Probably technically unsound terms for what I'm trying to convey, but I'll stand by my mess and own it, when 8k works it's looks visually amazing. Still doesn't feel as good as 250/500 to me though.

 

Anyway, I swapped out the viper for a mouse with the option of 250hz poll, as that and 500 always felt better. worth nothing that 125 always felt bad, in the sense that panning and frames would seemingly stutter as they still do.

The mouse is steel series prime, while I don't enjoy the way this mouse feels in my hand, I prefer the option of the 250 poll.

 

Here's a video I made opening the app, testing it out quickly and then towards the end changing between 250hz and 1000hz polling to test.

It looks like on 1k there are dots outside the range of the curve, whereas my 250 poll shows none. 

Don't put it past me that I've done everything right here, there may very well be user error as I'm not really familiar with the app not am that smart in general.

If there are any other settings I need to apply, change or anything with the test itself I need to do different or have done wrong entirely please let me know so I can amend!

 

 

 

Edited September 13, 2023 by sqwash

[TheNoobPolice]

You only need to enter DPI in the app for the velocity chart (since it charts real-world meters per second as units) and / or if you want to measure true DPI accuracy / deviation (can also be done on this website).

Your mouse has much better performance than any of mine as far as it's SPI timing (jitter) and counts distance consistency, probably why it also drifts far less than any of mine do.
You plot would not improve much if at all from any smoothing as it's remarkably un-noisy (most likely because there is some internal smoothing applied in the sensor / firmware which is why the plot is so nice).

So basically, although this is a big issue for you personally, you probably have less than or equal to the lowest drift of any modern mouse available, and I once again refer to my previous advice of you really should find something else to worry about. If anyone tells you they are getting less drift they are probably either not testing in real-world conditions or just talking nonsense.

[sqwash]

Howdy, sorry went away to the coast for a couple of days to enjoy the last of the sun.

 

Thank you once again for all that info.  Could I ask, is it well documented that USB 3 is worse for mouse than USB 2? 

And is it possible in even the slightest, that using a 3.0 driver to handle 2.0 ports is causing some issues?

 

Also, what is the reason for 1k polling being worse than 250?

Edited September 16, 2023 by sqwash

[sqwash]

I’ll also be creating another quick video, alternating between 250 and 1000 polling to show the clear visible difference between the two plots in mousetester.

just wondering what the scientific explanation for that difference is?

 

 

[TheNoobPolice]

On 19/09/2023 at 09:53, sqwash said:

just wondering what the scientific explanation for that difference is?

Well it's not really scientific, one of the main reasons is simply because Windows is not a RTOS and is objectively bad once timings get tight (note: there is one timing procedure called the Performance Counter which usually has 10mhz precision these days (it depends on hardware), but this is only really used for elapsed time measurement and can't be "spun" to delay a thread without high CPU usage, so most timing functions called by programs will use lower-resolution procedures).

A variance in poll time affects what distance is reported (i.e relative to what should be reported) when the OS gets data from the mouse. There may also be some per-mouse / on-board firmware differences between the selected polling rates which I don't have any insight on as isn't an area I am directly familiar with, but the way it generally works is the USB device has to flag an interrupt to the CPU in order to process any data sent/received and this can be deferred/delayed by the CPU for any reason  - and in a Windows environment these delays happen a lot. People have ran tests in other environments using the same USB spec and they can observe microsecond precision, so USB itself is not the issue here.

In Windows, if you use a mouse with 8k polling, for example, you will see totally crazy input cadence. Windows doesn't handle it well enough even just to update the cursor position every 125us, and especially games don't. A lot of the "better smoothness" difference people feel with 8k is actually just dropped packets - an objectively worse performance that they convince themselves is better - instead of every input arriving 125us, you will get some that arrive in like 40us or faster and some that take more than 500us, and any game most likely won't be able to process the former inputs unless it does a buffered read of raw input (which is by no means standard / common, and this by design pre-buffers inputs into an accumulator outside of the game which totally misses the point of what people think high hz is doing for them in-game anyway).

Anyway, I digress. I still use 500hz because it pretty much works well in all games no matter how they get input, results in low CPU thread usage, and is always going to be significantly above the max of any game frame rate I play and my monitor refresh rate which is the only important barometer imo.

[sqwash]

Hey mate, thanks for explaining that to me.

 

I’ve experienced the 8k polling woes first hand. When liasing with the input dude, was also informed that the undesired effect from 8k was due to a spam of raw input requests from certain processes/ apps? (Paraphrasing off the top of my head there)

I observed that behaviour when certain apps were opened in conjunction with other certain apps.

 

here’s an example of that with overwatch and discord. When discord opened, 8k became unusable. 

 

Edited September 20, 2023 by sqwash

[sqwash]

If I were to backshelf the drifting for now due to your advice, I’d still like to tackle why the mouse feels so different now than it did before.

So another feeling I get when using the mouse, is that it isn’t as responsive as it way. Like it is ever so slightly de-synced.

on most of the videos I’ve made for the (backshelved) drift, you can kind of see that the cursor and the mouse aren’t moving together, as in you can see the mouses position slightly ahead of the on-screen cursor, and that’s how it feels too. It used to feel more responsive and general and snappy.

 

also with regard to the mouse tester app, what are its limitations if any? Because I feel a MAJOR difference between usb 2 and 3 ports, always have. But when measuring the plots of both ports they show equal path consistencies, despite feeling so drastically different.

 

thanks again in advance mate.

[TheNoobPolice]

14 hours ago, sqwash said:

It used to feel more responsive and general and snappy.

also with regard to the mouse tester app, what are its limitations if any? Because I feel a MAJOR difference between usb 2 and 3 ports, always have. But when measuring the plots of both ports they show equal path consistencies, despite feeling so drastically different.

I'm very sceptical with "feels", I don't even trust my own. My perception of sens can change day to day depending on how tired or alert I am, and I don't see why this wouldn't also happen to other people. Sometimes the same sensitivity feels sluggish when tracking, sometimes it feels too responsive. The one thing that tends to feel consistent is off-screen movements like 180's which are more of a "muscle memory" (urgh, hate the term) but for the on-screen "hand-eye coordination" aiming aspect any human perception is not the stable barometer. So like I said before your feels can't be debugged, and if it doesn't feel good you should just change the sensitivity or some other factor such as mouse shape / weight / FOV etc etc.
I have actually been trying out a way to scale sens outside of directly axial movements to accommodate for subtle human perception changes in day-to-day feel, using linear space (p-norms) principles but with slightly different scaling, I think it works nicely but would need more time with it. Idea is one could scale up and down a slider depending on their feel without changing their 180 sens or vertical (read recoil control usually) movements. I'm aware of games that have done things like this with the camera that wouldn't show it measurements on sites like this, and I'm sure DPI Wizard doesn't want to start measuring diagonal sens and direction also lol

The MouseTester app doesn't have any interaction with the USB driver or version. It performs a standard read of Raw Input to find distance deltas and uses QPC() to find time deltas (0.1 microsecond precision). The USB 3 spec itself should not make a mouse behave oddly on paper, but it's down to each vendors implementation of it at the end of the day.

Edited September 23, 2023 by TheNoobPolice

[sqwash]

That sens perception thing you said you get, 100% agree with and get that too. I got into the habit of forcing myself to not change sens after a nights sleep and a fresh days boot. There’s a “warm-up” period which even with highly developed.. ‘Voldemort’ feels unnatural.

Also, friends never let friends drink and DPI. Never change sens after a laphroaig or 2, the next day is usually a “wtf was I doing” fest.

 

Anywho with regard to the sens changing, the order I like to do it is by firstly finding what feels nice on the desktop as I believe there’s the whole bleed over thing with windows sens and scaling etc. but once locked in on the desktop with windows sens, dpi, polling etc. I then would head into a game and use its test area to get in game sens right. Which for me would be only a baseline setting, as aim in training grounds and an actual game tend to always differ.

 

 

The comment you made with the off screen 180s, do you mean when on desktop screen or in-game? Because if in game, I used to be able to pull of those 180 snaps by feeling, but now it varies to such an incredible degree, it just isn’t consistent in the slightest. It’s feels like something is fighting against the movement. If I had to describe it better, it would be like the movement you would get on a mouse that was using an emulator for a console, like the xim. Not like “true” mouse response. Just like there’s some sort of acceleration/ negative acceleration, v-synchy drag.

Or do you mean the physical mouse itself feeling consistent when you move your hand?

in which case, yeah totally got you there!

 

That sens scaling slider depending on day sounds interesting, will that be a direct modification on the windows end or a middle man type of deal which works in conjunction with windows sens, if I’m even understanding correctly.

Regardless, will be keen to test that out if and when becomes available to do so!

 

Also, I know we’re back to me using the feelings word again and I’m sorry, but this one is more of a sidebar. When scaling modes are changed within say, nvcp, between aspect, full and none, why do they feel so different from eachother, despite nothing visually changing on screen?

Even when mouse was fine this would happen, I’m just curious as to why?

 

 

 

 

 

 

 

 

Edited September 23, 2023 by sqwash

[sqwash]

Hi again, it’s been a while but I just wanted to follow up with an obvious question I didn’t ask regarding the GitHub post from putz and the mouse behaviour.

 

if this behaviour is actually working as intended, then why was that post firstly accepted as an issue, and secondly subsequently resolved? A fix shouldn’t have to be rolled out for something which isn’t broken, right?

if that drift in motion was actually intended behaviour, surely all the people that confirmed that is was a new issue for them following an update would have been simply told that that is how mice actually function as opposed to being accepted as an issue?

 

Doesnt that highlight the fact that it is indeed an issue and not working as intended by that threads progression alone?

 

 

also happy holidays!

 

Edited December 23, 2023 by sqwash

[TheNoobPolice]

I don't think anyone said it's intended behaviour, it's a consequence of current optical sensor technology that is unavoidable - working as expected != working as intended. I'm quite sure the boffins at Pixart don't intend to make a mouse sensor that drifts, it's just the best they can do. 

Edited December 24, 2023 by TheNoobPolice

[sqwash]

Ok, pardon the poor wording on my part.

 

my point being, all those people noticed a change from the norm, which was acknowledged and addressed.

[TheNoobPolice]

Who knows? Maybe they just all don't know how mice work or maybe it's a slightly different issue they had.

In any case, as far as your issue that you highlight and demonstrate - it's very clear what it is, it's totally understood, and totally expected.

[sqwash]

36 minutes ago, TheNoobPolice said:

Who knows? Maybe they just all don't know how mice work or maybe it's a slightly different issue they had.

In any case, as far as your issue that you highlight and demonstrate - it's very clear what it is, it's totally understood, and totally expected.

So suddenly a group of separate individuals begin experiencing an issue which is entirely identical to mine and others currently, which is then confirmed by devs and most importantly, fixed. And your conclusion is they all don’t know how mice work?

 

multiple merged GitHub reports describing not a similar issue to mine, but an identical one as seen;

https://github.com/symless/synergy-core/issues/5291
https://github.com/symless/synergy-core/issues/5648
https://github.com/symless/synergy-core/issues/5607

 

im sorry, I don’t doubt your experience, but given the facts that prognosis is extremely far fetched and dismissive.

how things currently work and how things SHOULD and USED TO work are 2 entirely different things I’m afraid, and given the evidence and repeated testimonies from multiple individuals, clearly show that something isn’t working as it used to or should.

 

regardless I will continue searching for the solution to this glaring bug, thanks for your opinions.

Edited December 28, 2023 by sqwash

[TheNoobPolice]

11 minutes ago, sqwash said:

So suddenly a group of separate individuals begin experiencing an issue which is entirely identical to mine and others currently, which is then confirmed by devs and most importantly, fixed. And your conclusion is they all don’t know how mice work?

 

multiple merged GitHub reports describing not a similar issue to mine, but an identical one as seen;

https://github.com/symless/synergy-core/issues/5291
https://github.com/symless/synergy-core/issues/5648
https://github.com/symless/synergy-core/issues/5607

 

im sorry, I don’t doubt your experience, but given the facts that prognosis is extremely far fetched and dismissive.

how things currently work and how things SHOULD and USED TO work are 2 entirely different things I’m afraid, and given the evidence and repeated testimonies from multiple individuals, clearly show that something isn’t working as it used to or should.

 

regardless I will continue searching for the solution to this glaring bug, thanks for your opinions.

Well let's put it this way, if the symptom does indeed have the same cause as what yours is, and is indeed the same symptom, then they all absolutely don't know how mice work, because that's what happens well within normal spec and it's not up for debate.

So we then have to presume they are working to fix a different issue that just has similar sounding symptoms, and / or an separate issue that simply exacerbates the very normal symptoms that you have. I don't have the inclination to read through all their posts, because I already know what your issue is.

It's extremely clear and understood that you have expected behaviour, you can see in this test I shared before, that all mice drift, and usually in the same pattern with the same type of motions, even when moved in a totally consistent way by a machine (which would always produce less drift than a human hand). The difference is usually how much smoothing is applied internally or the accuracy of the sensor / implementation to begin with, along with surface differences that affect tracking performance slightly, but it never goes away entirely.

The idea that all these mice from different brands, all made by different engineers in different years, all just happen to have the same "glaring bug", and they all just happened to not notice it to fix it? And you claim what I said was far fetched?!

In any case, I've tried on multiple occasions now to reassure you but you don't seem interested in that. Anyone can see by moving their mouse around on the pad within screen space, and then moving the mouse back to the exact same starting position without it leaving the pad, that the cursor will now be in a different pixel on the desktop than in it's starting location. This is really nothing special or unusual I'm afraid. In any case, I've exhausted my interest on this particular topic, so I'll leave you to it.