SendInput/RawInput延迟一致性及输入栈延迟测量方案问询

一、SendInput发送与RawInput接收的延迟是否在所有程序中相同？ #

• 不会完全相同，甚至可能存在明显差异。延迟受多个关键因素影响：
  • 程序的线程优先级：游戏这类实时性要求高的程序通常会设置更高的线程优先级，消息处理响应更快；普通后台程序优先级较低，可能被系统调度延迟。
  • 系统输入队列负载：当系统同时处理大量输入事件时，队列拥堵会导致不同程序接收事件的时间差被放大。
  • 程序自身处理逻辑：部分程序会对RawInput事件做额外的缓冲、校验或预处理操作，这会增加额外延迟。

二、你的测量假设是否成立？ #

• 这个假设有一定合理性，但存在不可忽视的误差：
  • 合理性：你和目标游戏都是通过RawInput接收同一输入事件，系统会将事件广播给所有注册了RawInput的监听者，理论上事件到达各程序的时间差极小。
  • 误差来源：
    • 系统线程调度的不确定性：即使同时收到事件通知，你的程序和游戏的线程可能不在同一调度周期被唤醒，导致实际接收时间出现偏差。
    • 程序消息处理效率：如果你的程序消息循环存在阻塞（比如正在处理其他任务），会比游戏晚接收事件，导致测量值偏大。

三、更优的测量方法 #

• 进程内注入辅助线程：若拥有调试权限，可以在游戏进程内创建一个轻量线程，直接监听RawInput事件并记录时间戳。这种方法能直接获取游戏端的接收时间，误差最小，但需要处理进程注入的权限和兼容性问题。
• 利用游戏画面反馈：如果游戏有明确的输入反馈（比如按下按键后角色做出动作的帧），可以结合屏幕捕获工具（如使用BitBlt或DXGI接口捕获屏幕），记录SendInput调用时间和画面反馈出现的时间差。这种方法虽包含渲染延迟，但能反映用户实际感知到的整体延迟，适合无法进行进程注入的场景。
• 使用高精度时间戳：记录时间时用QueryPerformanceCounter（QPC）替代普通系统时间，QPC精度可达微秒级，能减少时间测量本身的误差。示例代码：

  LARGE_INTEGER freq, sendStart, inputReceived;
  QueryPerformanceFrequency(&freq);
  QueryPerformanceCounter(&sendStart);
  // 调用SendInput发送输入
  QueryPerformanceCounter(&inputReceived);
  double delay = (double)(inputReceived.QuadPart - sendStart.QuadPart) / freq.QuadPart;
  

内容的提问来源于stack exchange，提问作者rimuru