头动与画面更新之间的延迟需极低
别名: 运动到光子 · MTP · 头动延迟 · pose-to-photon
概念解释
头已经转到新朝向，光子还在画旧朝向的墙，世界就相对脑袋滑了一下。从头部开始运动，到对应那一帧的光进到眼里，这一段叫运动到光子延迟（motion-to-photon latency, MTP）。在头显里它必须极低——行业里常把可接受上沿放在二十毫秒附近，更严的旋转任务会把目标压到十几毫秒以下。桌面交互里五十毫秒的点击反馈仍可被当成「还算跟手」；同一数量级出现在头动上，房间已经在游泳。
「极低」是相对于前庭和本体已经报出的运动来说的。头显要维持的是一个静止的世界，不是一个跟手的指针。
机制
转头时前庭半规管几乎立刻给出角速度，脖子的本体感觉同步到达。视觉若晚到，两套「我转了」的证据对不上：前庭说世界应向反方向扫过视网膜，实际的扫过却晚了一截。人把世界当成稳定的参照，延迟被解释成世界在动，而不是自己的头在动。稳定参照一松，站姿与空间定向都要重新估。
头显把视场贴在脸上，没有显示器边框当「这是一块屏」的借口。延迟因此没有地方躲：每一度头动都在整幅视网膜上要立刻兑现。指针延迟可以靠预测点击来补；世界延迟没有「点一下」这种离散事件，它是连续的空间承诺。所以同一毫秒数，在 GUI 里能过，在头动上过不了。
怎么研究
用可控的延迟注入：头姿按时采样，渲染或显示被人为推迟一档已知的毫秒数，让人判断世界是否在头动时滑动，或做指向、对准任务。Adelstein、Allison、Jerald 这条线测的是可检测阈和操作阈，不是平均帧时间。
自变量：注入的 MTP 毫秒数、头动角速度、场景里近处结构的密度。 因变量：能否检出「世界在滑」、指向误差、主观的「贴住头 / 拖在后面」。
测量必须从真头动计到真光子，用高速相机对着头显画面和头上的标记对拍。只读引擎里的帧耗时，会把显示驻留和扫描时间漏掉，报出来的数偏小。
边界
坐着看固定画面、头几乎不动时，MTP 不被采样，再高的延迟也可以「看起来没事」，不能用这种任务给头显签字。慢速平滑转头比快速点头更难检出同一延迟，验收要用自然出现的快速小节，不要只用展览里的慢转。视频透视还要叠一层相机延迟，光学透视没有这一层，两台机器的「极低」不是同一个预算。预测（按当前角速度外推）能在短时间里把有效延迟压下去，但它依赖运动可预测；急停和转向反转时预测会加错，不能把预测当成长久的低延迟。阈值随个体和任务变，二十毫秒不是生理学常数，是工程上常用的上沿。
怎么落地
- 把 MTP 写成头显体验的硬预算，而不是画面特效的质量项。内容再精致，头一转世界跟着拖，预算就没保住。
- 验收用快速点头和左右急转，不用慢速展览转场。近处有明确棱线的场景比天空盒更能暴露延迟。
- 不要用引擎帧时间代替 MTP。验收数字来自头动到光子的对拍或平台提供的 MTP 计数，来源写进报告。
- 验证：在目标设备上做三次短促点头，请没做过这个项目的人看世界是否在点头时晃。能指出「墙在追我的头」，延迟就不在「极低」里——先把毫秒数压下去，再谈别的画质。