实测 Magic Mouse 2 鼠标的采样率为 88.9Hz 加减 0.1Hz （连续 5 秒，每秒更新，Windows 10 + BootCamp-6.1.7748 鼠标驱动）

测试工具 Pointer Movement Timing Analyzer
公测版 https://beta.tourofdreamland.net/device-tests/hid/pointer-movement-timing-analyzer/
预览版 https://codepen.io/fuweichin/details/vYPEBNM

主要问题是这 HID 采样率不是 60Hz 屏幕刷新率的整倍，加之采样率不高，从而造成垂直同步渲染时明显的指针移动微观结巴(micro stuttering)。

屏幕仿真器 公测版 https://beta.tourofdreamland.net/device-tests/screen/screen-simulator/

实测通过[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/

不支持。

各版 HDMI 规范中均没提到 DCI-P3 色域，
（见 https://web.archive.org/web/20190527221508/http://www.dxdlw.com/bbsupfile/2013/10/21/2056366266/HDMISpecification2.0.pdf ）

Windows API HDMI 部分中也没提到。
（见 https://learn.microsoft.com/en-us/uwp/api/windows.graphics.display.core.hdmidisplaycolorspace?view=winrt-22621 ）

所以

不过 HDMI 2.0 开始支持更广的 Rec. 2020 色域，Rec. 2020 基本覆盖 DCI-P3 。

首先要明确的是：一套微型机物理硬件不能直接运行多个操作系统，即使是某些双 CPU （区别于双核）的服务器也不能，要运行多个操作系统必须加虚拟化层，无论是用虚拟化硬件还是虚拟化软件。

我曾设想了一个“双系统互为虚拟化主客同时运行”的方案，最初尝试 Windows-macOS 组合但没成功，不过对于 Windows-Linux 组合倒是可以，大致步骤：

0. 笔记本配备两块内置磁盘，足够的内存大小，其中一块盘安装了 Windows 。

1. 通过 AIDA64 软件查看，并拍照记录下 Windows 的主板 ID
2. 在 Windows 安装 VirtualBox ，用 VirtualBox 将 Linux 安装到另一块磁盘（ 参见 https://blog.csdn.net/flashdelover/article/details/102745140 ）
3. 从 BIOS 启动到 Linux ，安装 VirtualBox ，在 Linux 中创建 Windows 那块物理盘的虚拟盘 vmdk ，并创建 Windows 虚拟机，编辑 Windows 的.vbox 文件设置虚拟机的主板 ID 为物理机的主板 ID （此举是为避免当 Windows 系统以虚拟机方式启动时主板 ID 值变化导致 Windows 或者那些检测主板 ID 的软件 License 变得无效）

至此，两个操作系统可互为主客，你可以
+ 开机进入 Windows ，并启动 Linux 虚拟机
+ 开机进入 Linux ，并启动 Windows 虚拟机

为了让 Windows 主机与 Linux 虚拟机集成更加紧密，参加这篇文章 https://blog.csdn.net/flashdelover/article/details/125587986

@fuweichin 要 4K 60Hz 请用 DisplayPort 线缆，或 DisplayPort 转 HDMI 2.0 线缆

8 代～ 10 代 Intel UHD Graphics 就够。注意 11 代 Intel 不支持 4K HDR Blu-ray 且大都不支持 Hackintosh ，7 代 Intel 大都不支持 Windows 11

看你要模拟哪款 Macbook ，选 2020 年(Intel 11th Gen)之前、离你要模拟那款 Macbook 同等定位配置最接近的翻新 /二手笔记本 PC 。

或者直接选 2020 年(Apple M1)之前的一款黑微软笔记本（即 Intel CPU Macbook ），这样的还能装 Windows ，如果题主只认黑苹果，那我这句就偏题了。

@kujio 对于锂电池，承认过放 /低电量损害电池，但满电（吃饱了）和过充（吃撑了）不是同一个概念。“推荐少吃多餐”没问题，但我反对“吃饱了不好”的说法。

1. 片源是否是 Real HDR （区别于 Fake HDR ）
2. 播放器是否支持 BT.2020 解码且配置播放器采用 10bit 输出（推荐 PotPlayer ）
3.显示器是否支持且配置为使用 Adobe RGB/Display P3 色域

如果三个条件都满足，那么你看到的才可能是逼真的 vivid HDR （定时做显示器颜色校准更佳），否则呵呵，对比起来你可能会很受伤

通过 HDR 认证的显示器列表：
https://displayhdr.org/certified-products/

P.S.参数越好看价格越高高，量力而行。