fuweichin

实测通过[usbhidf]( https://github.com/LordOfMice/hidusbf)可以在驱动层面实现降低回报率，虽然只支持降到 125*2ⁿHz (其中 n 为整数)。

发现 VESA 的 MediaSync Display 规范关注的就是视频播放帧显示均匀性的问题。

突然想起我的笔记本电脑内置屏幕支持 48Hz 和 60Hz 两种刷新率，切换到 48Hz 后测试发现 requestAnimationFrame 间隔是均匀的（抖动在 0.5ms 内），估计这个 48Hz 选项就是为了播放 23.976Hz,24Hz 视频而考虑的。虽然手动切换刷新率，不过有胜于五。

然而 125Hz 鼠标回报率 vsync 到 48Hz 显示器刷新率时由于不是整倍，又会造成运动不均匀。预言：未来的鼠标可能会支持 VRP(variable report rate)。

再举些例子：
当一个高分辨率(3840x2160)显示器由操作系统设置为低分辨率(1920x1080)模式时，Windows 显示的信号分辨率还是 3840x2160 ，这算用到映射吧。
播放 48KHz 采样率的音乐，输出到只支持 44.1Hz 的音频接口，这算用到映射吧。

欢迎拿测试数据说话，臆测的靠边。

不仅仅是后端语言，前端周边相关的都得学点，比如：
+ 在设计师正式出稿之前做个简易 logo
+ 在后端开发人员实现功能之前做个 mock 服务
+ 在详细需求出来之前把概要需求整理成文

当然如果你是被按着头学的，那就当我没说。

最近买了个 Surface Precision Mouse 测试平滑滚动，实测 BLE 连接回报率 133Hz 左右，USB 连接回报率 1000Hz 。

之前做了个简单 VSCode 扩展程序练手，大约用了 2 天。
实用价值不高，功能如下：
+ 移动所选文本到新文件 （包含对<script>、<style>的特别处理）
+ 插入文件内容
+ 插入相对路径

手机触控的采样率我也测了，与屏幕刷新率设置是同步的。相对屏幕刷新率事实标准 60Hz ，Android 手机如果开启高刷新率 120Hz ，那么触控的峰值采样率可升到 120Hz ； iOS 手机如果开启低电量模式，那么屏幕刷新率会降到 30Hz ，触控峰值采样率也会降到 30Hz 。

鼠标在使用高采样率（或称轮询率，回报率）时
1. 能以更低的延迟及触发 click(mousedown+mouseup)事件，有助于 FPS 游戏点击的响应速度
2. 能以更高的频率触发 mousemove / drag 事件，
有助于提高鼠标手写 /绘画的笔触采样密度，但是对于即时渲染显示来说则没有必要，会触发大量无助于显示输出帧率的计算，更费电。

所以我能想到的解决方法是：必要时，给 mousemove 事件作 throttle 处理，或交由操作系统 /鼠标驱动来做，或交由应用框架来做，或由对采样率有明确需求应用程序来做。

其实 Firefox 浏览器默认就会对 mousemove 进行 throttle 处理，使得 mousemove 事件触发频率不高于屏幕刷新率。但是万一某些应用程序期望使用高采样率呢？

我们需要一套 Spec 和一套 API ，比如：规定浏览器默认对 mousemove 事件进行 throttle 使其出发频率不超过屏幕刷新率，并提供 API 让应用程序可以配置偏好的 mousemove 采样频率及区间。当然也可反过来，规定浏览器对 mousemove 事件默认要按原始采样率触发…

Web 规范完成后，其它应用框架可能会跟进。

我只是发现问题，期望有人到 WICG 发起提议，编写规范或参与讨论。

我期待的鼠标是其采样率与显示器刷新率一致（即支持 60Hz, 120Hz, 144Hz 之类的采样率）且可以像切换显示器刷新率一样切换鼠标采样率。

P.S. 采样率高非我所需，最好是能刚好喂饱显示器，还得保证接受端的间隔抖动小。

反面教材： https://appuals.com/mouse-lagging-windows-11/