Latency decreases after switching mouse dpi. Why?

[Chief Blur Buster]

Soon im gonna be moving pc to different places because im pretty sure its gotta be electricity and if its not ill honestly be so lost on what to do .

Nipping this in the bud -- this specific item isn't electricity related. Too much mis-blame about electricity here.

This known DPI-switch-and-back problem is generally caused by a bug in drivers / software stacks; a more correct solution is needed.

OS data and driver data is needed -- e.g. whether you are using the Microsoft driver or the vendor drivers, etc.

[Chief Blur Buster]

Each time after changing the DPI and returning to its value, the mouse works faster and sharper.
Can you test this on your mouse and computer?

Very interesting! I've heard of this problem, and it is annoying when this happens.

Can you tell me if you are using the Microsoft driver or the vendor-specific driver?

[loccomacco]

Soon im gonna be moving pc to different places because im pretty sure its gotta be electricity and if its not ill honestly be so lost on what to do .

Nipping this in the bud -- this specific item isn't electricity related. Too much mis-blame about electricity here.

This known DPI-switch-and-back problem is generally caused by a bug in drivers / software stacks; a more correct solution is needed.

OS data and driver data is needed -- e.g. whether you are using the Microsoft driver or the vendor drivers, etc.

Source?

[loccomacco]

Each time after changing the DPI and returning to its value, the mouse works faster and sharper.
Can you test this on your mouse and computer?

Very interesting! I've heard of this problem, and it is annoying when this happens.

Can you tell me if you are using the Microsoft driver or the vendor-specific driver?

I wonder why this one attracted your attention, because there was already a post in the past about it

[Chief Blur Buster]

Source?

I've seen this post pop up on and off over the last many years that changing settings back-and-fourth often fixed things.

As a software developer, I already know there are many bug mechanisms that can arise from this -- unfortunately, it's more common of a programming goof-up in many contexts, including this one. There's also sometimes time-delay bug between a sensor Hz and a USB Hz (the sensor operates at a different frequency). There's also drivers that don't properly re-initialize USB settings until you reboot the settings via a simple settings switch, to force the registers to be rewritten correctly. (This applies to almost anything including computer monitors -- e.g. turning off-then-on overdrive can sometimes fix overdrive).

There's a logical explanation for specific types of computer programming mistakes that omits an Initialize() or UpdateSettings() type of code subroutine.

I wonder why this one attracted your attention, because there was already a post in the past about it

I pounced fast on this one because of the (extremely excessively frequent) electricity misblame.

Such misblame prevents the correct programmers from fixing the bugs -- best to focus on the logical possible causes before the less probable causes.

If you are a software developer, you already understand the common "forgotten initialization" bugs. The type of problem that requires you to change a setting back-and-fourth to fix.

I have to stop the EMI fakery as quickly as possible, and filter the EMI only to the genuine stuff. The presence of the forum is frequently giving too many people an excuse to blame something new.

[loccomacco]

Source?

I've seen this post pop up on and off over the last many years that changing settings back-and-fourth often fixed things.

As a software developer, I already know there are many bug mechanisms that can arise from this -- unfortunately, it's more common of a programming goof-up in many contexts, including this one. There's also sometimes time-delay bug between a sensor Hz and a USB Hz (the sensor operates at a different frequency). There's also drivers that don't properly re-initialize USB settings until you reboot the settings via a simple settings switch, to force the registers to be rewritten correctly. (This applies to almost anything including computer monitors -- e.g. turning off-then-on overdrive can sometimes fix overdrive).

There's a logical explanation for specific types of computer programming mistakes that omits an Initialize() or UpdateSettings() type of code subroutine.

I wonder why this one attracted your attention, because there was already a post in the past about it

I pounced fast on this one because of the (extremely excessively frequent) electricity misblame.

Such misblame prevents the correct programmers from fixing the bugs -- best to focus on the logical possible causes before the less probable causes.

If you are a software developer, you already understand the common "forgotten initialization" bugs. The type of problem that requires you to change a setting back-and-fourth to fix.

I have to stop the EMI fakery as quickly as possible, and filter the EMI only to the genuine stuff. The presence of the forum is frequently giving too many people an excuse to blame something new.

Ok accepted, I'm not a programmer for now but I'm in this road so I can confirm what you said.
But still there is something remained, what if he changes his mouse to a completely different brand as well as windows (a complete fresh installation) without any success, then what you will have to say?
Now I recommend everyone who claims changing mouse DPI back and forth, makes things better, please fresh install your windows as well as buy new different mouse from another brand, just for the record to see if it's software related or not.
Isn't it a good troubleshooting? Correct me if it's not.

[Chief Blur Buster]

The moral of the story is that troubleshooting is a painful time drain, no matter the Who/What/When/Where/Why.

Rare/unusual problems will still exist. However, major course corrections are needed to save lots of wasted time when there's clear, more common alternate logical paths.

[F1zus]

Each time after changing the DPI and returning to its value, the mouse works faster and sharper.
Can you test this on your mouse and computer?

Very interesting! I've heard of this problem, and it is annoying when this happens.

Can you tell me if you are using the Microsoft driver or the vendor-specific driver?

Thanks for your reply, chief. I only use microsoft drivers. Mouse logitech g pro wireless, polling rate 1000Hz, 1600dpi (but it doesn't matter). I have tried other mice such as the Logitech G403, Red Square 1337 (sensor 3360) and it also has this problem.
Right now I installed cs:source on my phone (android 10, asus rog phone 3), launched the game and connected the mouse by wire and switched dpi several times. The mouse is a little more responsive again.
So I think it's not just the drivers. It seems to me that some hidden power-saving features of the mouse sensor are disabled after switching dpi or the mouse sensor goes to another state.

[loccomacco]

The moral of the story is that troubleshooting is a painful time drain, no matter the Who/What/When/Where/Why.

Fact.
I could say a fresh installation is a common thing for most of us, but your fact still remains true, it takes a painful time.
But at least, it may not take money if you borrow a mouse from your friend.
Btw it's a way of troubleshooting, if you're ok with wasting time and perhaps money, do it.

[loccomacco]

Each time after changing the DPI and returning to its value, the mouse works faster and sharper.
Can you test this on your mouse and computer?

Very interesting! I've heard of this problem, and it is annoying when this happens.

Can you tell me if you are using the Microsoft driver or the vendor-specific driver?

Thanks for your reply, chief. I only use microsoft drivers. Mouse logitech g pro wireless, polling rate 1000Hz, 1600dpi (but it doesn't matter). I have tried other mice such as the Logitech G403, Red Square 1337 (sensor 3360) and it also has this problem.
Right now I installed cs:source on my phone (android 10, asus rog phone 3), launched the game and connected the mouse by wire and switched dpi several times. The mouse is a little more responsive again.
So I think it's not just the drivers. It seems to me that some hidden power-saving features of the mouse sensor are disabled after switching dpi or the mouse sensor goes to another state.

Nice, this was another way of troubleshooting, but in a mobile device, because of it's small screen, it's more hard to compare before and after a thing, better to do it in your same PC, like the way I suggested.
So it means it's not software related then, same issue in your phone too. Am I right?