C8.06.2Foveation latency设计研究

降质边界移动过慢会被察觉

别名: 注视渲染延迟 · 岛更新滞后 · foveal island lag

概念解释

注视引导渲染的全分辨率岛必须跟着扫视走。从眼睛开始移动,到新位置上已经画出高质量像素,中间隔着追踪、传输、渲染和显示。这段更新延迟若长过视觉系统重新编码的窗口,人会在着陆点看见一团尚未追上的模糊,或看见质量边界像帘子一样拖在注视后面。问题不是周边降了多少,而是边界能不能在下一次注视开始时已经就位。

机制

一次典型扫视只要几十毫秒;扫视抑制在着陆后还要几十毫秒才完全解除。高质量岛若在抑制解除之后仍停在旧位置,新注视会先编码到低质量像素,再看到质量“赶过来”。Albert 等人在头显里测过:延迟到约 50–80 毫秒量级时,被试开始稳定地报告伪影,具体阈值随降质梯度变陡而下降。更陡的周边削减等于更窄的容错,同样的延迟更容易被看见。

预测型补偿(根据扫视方向提前把岛挪到预计落点)可以买回一部分时间,但预测错了会把高质量画到错误位置,比迟到更显眼。固定放大岛半径也能掩盖延迟,代价是节省算力变少。

怎么研究

把端到端延迟做成自变量:在眼动样本和渲染提交之间插入已知的缓冲。让被试做扫视到新目标的任务,报告是否看到模糊闪一下、质量边界滑动、或着陆点发虚。 同时记录扫视幅度,因为大幅度扫视给系统的预警更长,也让预测更难。 桌面模拟很难复现头显的光子时间和扭曲,结论要在目标头显上重测。不要只用平滑追踪(pursuit)来测延迟:平滑追踪的速度远低于扫视,会严重低估问题。

边界

用户几乎不扫视、只做慢速追踪的应用(某些观看类内容),延迟容限更宽。周边质量若降得很温和,迟到的边界也不容易显形,但那样本来也没省多少。追踪丢样本、眨眼期间的空洞,会让岛停住或乱跳,表现得像延迟一样,需要与真延迟分开诊断。部分偏头痛和视觉压力敏感者,会在实验室“刚可察觉”的延迟下就无法继续。

怎么落地

  • 把眼动到光子的延迟预算写进渲染管线,优先于多画一档特效;扫视密集的应用按更严的阈值来。
  • 用适度放大的岛或短时预测来掩盖不可再压的延迟,并在预测失败时迅速回到以当前样本为准。
  • 验证:在目标头显上做大幅度扫视到高对比目标,询问着陆瞬间有无模糊或边界滑动,而不是只看平均帧率。

延伸

  • 同组C8.06.1 周边区域降质以节省算力 · C8.06.3 依赖眼动追踪失效时需安全降级
  • 相邻C8.01 注视与扫视 · C2.10 触摸延迟与直接性
  • 站内检索foveation latency · saccade-contingent rendering · end-to-end delay

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/C8.06.2