ayo

yes absolutely! basically, it's a very long and nuanced point but my shortest explanation is as follows (be ready, it'll still be VERY long, that's why I want to make a video with MANY visualizations and examples): DPI are a parameter of the SENSITIVITY of the optical flow algorithm that runs on the DSP. ANY sensor, in the WORLD, as it increases sensitivity, decreases its snr (signal to noise ratio). So, increasing DPI in a vacuum is equivalent to increasing ISO in a camera or gain in a microphone. So, when do you increase ISO in a camera? when the current value is insufficient to pick up sufficient signal (light) for your "need" (in that case, the correct exposure of the image). Gain in a mic? Same thing, you increase it (at the cost of a higher noise floor) until your signal (voice, instrument, whatever) is picked up and sufficiently loud. So, when should one increase DPI? DPI is NOT, no matter how many times this analogy is used, the "resolution" of the sensor. The sensor is a fixed size array (it can't magically increase its physical size) of pixels (usually not many, something like 23x23). DPI is a function of distance, not time, not resolution. It determines the minimum amount of distance, as reconstructed by an optical flow algorithm running on the DSP of the sensor, needs to have been observed before the sensor reports a count to whatever is currently reading the sensor (a microcontroller, typically). WHY am I saying all of this massive preamble? Because increasing dpi has GUARANTEED negative effects, which are immediately obvious if one analyzes the issue asymptotically: as the speed of motion approaches infinity, since the sensor takes "samples" of the mouse surface (called sensor framerate, which is completely unrelated to hz/dpi, and usually caps at about 20k fps) at a given frequency (in time, not in distance!), it is immediately obvious that lower dpi would allow the algorithm on the DSP to hit the "no signal left" threshold (assuming it has leverages heuristics that aggregate multiple frames, when available) at a higher speed than higher dpi. Basically, imagine I move so fast that two subsequent frames only overlap at the very edges, and barely. this sample is inherently very "noisy", as in, it's much more likely that random/high frequency features (idk, for example, patterns in the weave of the pad) will be similarly represented as the underlying signal. If I am at a higher DPI, it means that my algorithm is starved of the possibility to wait multiple frames now to "decide" how to reconstruct the motion. This is just a very long way of saying that, like in any other sensor, indeed, raising dpi raises the noise floor of the reconstructed signal. So, since it's a universal truth that, by some non-zero value, higher DPI decreases the signal to noise ratio, one has to figure out where the correct threshold is, at which the extra signal picked up (more granular motion reconstruction) makes up for the decrease in signal to noise ratio. Usually, I try to shorten this to: "you should use the lowest DPI that, at your cm/360, does not cause the minimum camera rotation (which is purely a function of the in-game sens, not the dpi itself) to be so large that you start incurring motion clarity or "pixel skipping" issues". As you can see, I never mentioned latency. Why? Because of what I said in the other post. If you keep cm/360 fixed, the likelihood of the "latency" savings from increasing the density of your imaginary lattice that is superimposed to your motion (my example from earlier about how as you double dpi, every other dot you end up at the same place AT THE SAME TIME), to be relevant, is just astronomically low. It's not even in the conversation. IN the specific case of the X2h, for some reason, it seems like at higher dpi there also exists a SPECIFIC problem that might be a firmware bug, that I am yet to fully analyze and dissect, so I don't want to give my current thesis on the matter publicly. So all of that said, 800dpi, as long as I am playing very low sens (like this), is absolutely adequate for my needs, AND I am then sure that the DSP on the sensor will always have plenty of data available to leverage whatever smart trick or heuristics the engineers that wrote it have implemented to increase the accuracy of the motion estimation. Basically, you can imagine cm/360 as how bright the environment is when taking a picture, or how loud your voice is when speaking into a mic. CM/360 is really what determines your DPI. It's just very hard to quantify EXACTLY where the threshold is, so I hate giving blanket statements of "higher dpi is better" or "lower dpi is better". It's a tool. I wouldn't use 12800 ISO on my a7r iv when in my brightly lit office. I wouldn't use 70db gain on my SM7B when speaking 2cm away from the mic. Therefore, I wouldn't use 1600/3200 dpi at 85cm, as I perceive no visible benefit, while definitely incurring a cost in signal to noise ratio when I flick faster. Also, as dpi increases at a fixed cm/360, your battery life gets worse and your in-game fps (not stutters) get worse, as the game now has to compute more rotations of the camera per second, and your mouse is needlessly sending more information over RF per second, using more battery. Basically, if you "saturate your polling rate" by using higher DPI, you are just making sure that you are at the least efficient use of your battery, and the most taxing computational state for your game (and also the highest level of interrupt storming for your OS). And since the x2h already has a very short battery life, 800 dpi is the way for me. P.S. no one, apart from Pixart and Logitech employees, can really know what the real answer to my thoughts about whether or not the DSP actually does actually use DPI internally as part of its algorithm, or it just estimates motion according to other metrics of confidence internally and then reports aggregates of its internal state via the motion registers according to DPI. I am just saying that there is no world, though, in which you'd have a BETTER signal to noise ratio with higher DPI. That part is just impossible, unless a bug/unintended behavior is occurring. You can have less signal, yes, so much so that it's insufficient to properly reconstruct the motion in a sufficiently accurate way, but you will also have very very very little noise, and each of the very sparse samples will be very very very very accurate.