高回报率鼠标在Windows似乎会丢数据，大家来测测

2023-05-20 19:34 作者:勉強上手 0人读过 | 我要投稿

更新：换了新电脑和最新版Win11以后似乎没问题了。建议用高回报率鼠标前更新到最新版Win11，并且用mousecomparator和低回报率鼠标对比一下看稳不稳定。

测了下刚到的VGN 4khz接收器，在开2khz和4khz回报率的时候dpi不稳定，但在1khz下正常，不知道是丢包了还是测试方法有问题。

我在1600dpi下用机器左右移动2英寸测得的结果是这样的：

测试工具是github.com/benkyoujouzu/mousesniff。测试结果上的横轴是时间，纵轴类似于mousetester里的xsum，是开始测试以来鼠标回报x点数的总和。理论上说，1600dpi下移动2英寸应该回报3200个点，可以看到1khz的测试结果下鼠标每次移动都回报了大约3200个点，但是4khz和2khz下回报的点数不到3000个，少了很多点，而且波动很大。用mousetester也能测出类似的结果。

考虑到大部分读者都没有机器，下面介绍一个用手测的方法，用到的工具是mousecomparator。www.overclock.net/threads/mousecomparator.1570462/

mousecomparator的测试步骤
0. 把vgn和对比鼠标调到相同的dpi
1. 用vgn鼠标点Mouse 1
2. 用对比鼠标点Mouse 2
3. 按F1开始收集数据，把两个鼠标同时横向拖动相同的距离（就移动一次，不要来回晃）
4. 按F2停止收集数据
5. 点Calculate计算两个鼠标回报距离的比例，应该接近1.0

试试vgn不同回报率下的结果，我在1khz回报率下结果很接近1.0，但4khz回报率下结果在0.6-0.85波动。

这意味着4k hz下dpi会有很大的波动，类似于加了个Sensitivity Randomizer。

最后，不管是mousesniff，mousetester还是mousecomparator用的都是GetRawInputData这个api获取鼠标数据，我不太确定这个api是不是在超过1khz回报率的时候会出问题，不过起源引擎（至少在之前泄露出来的版本）就是用的这个api。

发这篇文章主要是希望有其他高回报率鼠标的读者也尝试一下上面这个mousecomparator的测试，试试有没有类似的现象，看看是api的问题还是鼠标或者接收器的问题。（更新：看来更可能是API问题）

230522更新：

看到一个帖子说GetRawInputData在高回报率可能会出问题。（ forum.unity.com/threads/windows-mouse-raw-input-mouse-handling-broken-in-rewired.1172786/ )

于是尝试用GetRawInputBuffer实现了一个读原始数据的东西，发现2khz回报率下几乎没问题了，但是4khz回报率下仍然会丢包。一个合理的猜测是windows在处理不过来的时候会把输入的数据丢掉。

（用GetRawInputBuffer的实现 github.com/benkyoujouzu/mousesniff/releases/download/v0.0.0-alpha.0-buf/mousesniff-v0.0.0-alpha.0-buf.exe）

用了GetRawInputBuffer，2khz在508mm/s也没太大问题，

4khz在64mm/s左右的速度时基本也没问题

但是在127mm/s以上就开始少量地丢数据了

254mm/s以上丢数据就比较明显了。

就目前的结果来看，丢数据的原因更可能是API或者电脑性能的问题，建议大家在fps游戏里暂时还是用1khz回报率，因为：

有读者反馈其他的高回报率鼠标在用GetRawInputData的mousecomparator上也会出问题。
我暂时没有找到比GetRawInputBuffer更好的办法，而且考虑到很多开源的游戏引擎都还在用效果更坏的GetRawInputData，很多游戏可能也还在用GetRawInputData，这个API在2khz回报率都会明显丢数据。
虽然我的CPU比较一般，但测试是在cpu空闲的时候进行的，实际游戏的时候cpu的压力会更大，即使是比较好的CPU也有可能出现类似的问题。

当然也还不能完全排除：