Chapter 143: Latency Reduction Techniques
VR/AR 延迟优化的主问题是：当用户头部、手柄或眼睛已经移动时，最终显示到眼前的图像如何继续贴合这个新的感知状态。读完本章后，读者应能追踪一帧 XR 画面从姿态采样、预测、渲染、提交、合成到显示发光的路径，并能判断延迟来自应用渲染、运行时合成、预测误差、显示扫描还是输入处理。
本章以一个贯穿场景展开：用户戴着头显看一个固定在房间墙面上的半透明控制面板，头部向右快速转动，同时手柄指向面板上的按钮。目标体验是面板在世界中保持稳定，按钮反馈跟随手柄输入，头转动时画面无明显抖动、拖影和跳帧。这个场景能暴露 XR 延迟优化的完整链路，因为它同时包含 head motion、controller input、world-locked content、stereo view、depth、runtime compositor 和 display scanout。
本文采用两个版本边界。跨平台时间与帧同步模型以 OpenXR 1.1.60 Specification 为基础；平台案例使用 Microsoft 的 Rendering in DirectX - Mixed Reality 说明预测、临近绘制前刷新 view/projection 和提交 depth buffer 对稳定性的作用。Microsoft 文档对应 legacy WinRT native APIs，本文只使用其中可观察的数据路径案例，跨平台实现仍以 OpenXR runtime / compositor 的抽象理解为准。
延迟降低的核心结论是：XR 不能把优化目标压缩成“渲染更快”一个动作。稳定体验来自四类动作同时闭合：用预测姿态渲染目标显示时刻，用 late latching 缩短姿态写入到 draw 的距离，用 timewarp / reprojection 在提交后继续修正头动误差，用 evidence map 把 motion-to-photon、reprojection rate、dropped frame、judder 和眩晕反馈连成风险判断。
143.1 VR/AR 迟延的感知问题与影响
VR/AR 中的迟延是用户动作与眼前图像之间的时间偏移。普通 2D 游戏中，输入延迟主要体现为操作反馈慢；XR 中，头部姿态本身决定相机视图，延迟会直接改变画面与前庭感受之间的关系。用户向右转头时，内耳已经感到旋转，眼睛看到的世界如果仍停留在旧姿态，系统就产生 motion-to-photon 偏移。
Motion-to-photon 指从物理运动被采样到对应图像光子到达眼睛之间的总时长。它覆盖 sensor sampling、tracking fusion、application update、rendering、runtime composition、display scanout 和 panel response。这个指标比 GPU frame time 更适合评估 XR 舒适性，因为 8 ms 的 GPU 渲染仍可能叠加旧姿态、排队等待、合成延迟和显示扫描，从而变成更高的感知延迟。
贯穿场景中，半透明控制面板是 world-locked content，也就是内容绑定到房间坐标。用户头向右转动后，正确结果是面板相对墙面保持稳定，视野中面板位置随着头部视角自然移动。延迟过高时，面板会像粘在屏幕上后再追赶墙面，用户感到画面漂移；预测误差过大时，面板会先过冲再回拉；帧节奏不稳时，面板边缘会出现 judder。
Judder 是连续帧在运动相位上产生不均匀跳变的视觉现象。它常出现在 missed vsync、合成补帧比例升高、应用 frame pacing 波动或显示刷新与提交节奏脱节时。用户看到的现象表现为世界锁定对象在空间中按不均匀步长移动，低帧率只是其中一个可能来源。对半透明控制面板这类带直线边缘和文字的 UI，judder 的感知强度通常高于自然场景背景。
Prediction error 是预测姿态与真实显示时刻姿态之间的差值。XR runtime 会根据最近的 tracking 数据预测某个未来显示时刻的 head pose，应用再用这个姿态生成 view matrix。预测时间越靠近真实显示时刻，误差通常越小；预测窗口越长，快速转头、抖动、追踪丢失和滤波滞后越容易放大误差。OpenXR 的时间模型要求应用围绕有意义的 runtime timepoint 推理，例如 frame predicted display time，并把定位查询绑定到这个时间点。
| 感知问题 | 直接现象 | 管线中常见来源 | 可观察证据 |
|---|---|---|---|
| 头动滞后 | 世界像跟着头拖动 | 旧 pose 渲染、提交过早、合成修正不足 | motion-to-photon 偏高、pose age 偏高 |
| Judder | 运动步长忽快忽慢 | missed vsync、frame pacing 波动 | dropped frame、present interval 不稳 |
| Reprojection artifact | 边缘扭曲、遮挡错误 | 使用上一帧重投影补偿新姿态 | reprojection rate 升高、depth/motion vector 缺失 |
| Prediction overshoot | 物体先偏移再回拉 | 预测模型与真实运动不匹配 | prediction error 在快速头动时增大 |
| Comfort risk | 眩晕、眼疲劳、恶心 | 视觉与前庭长期不一致 | 用户反馈与指标峰值同步出现 |
感知延迟还会影响交互可信度。手柄射线点中按钮时，按钮高亮如果晚于手部动作，用户会降低操作速度；眼动选择如果与 gaze point 延迟错位，系统会把高亮或 foveated region 放到旧注视点附近。VR/AR 的延迟优化因此要同时处理 head motion、controller input、eye gaze 和 rendered image。只优化其中一条路径，体验仍会被另一条路径拖慢。
本节的判断顺序是：先确定用户感到的是头动滞后、交互滞后、画面跳动还是重投影伪影；再把现象对应到 head pose、input sample、application frame、runtime compositor 和 display scanout；最后用 motion-to-photon、frame pacing、reprojection rate 和 dropped frame 证据验证。这个顺序能把主观不适转成可定位的管线问题。
143.2 渲染管线与交互延迟优化策略
XR 延迟优化从帧生命周期开始。应用通常先等待 runtime 给出下一帧节奏，再取得预测显示时间，然后基于该时间查询 view pose 和 input state，接着录制渲染命令、提交 swapchain image 或 composition layer，最后由 runtime compositor 执行畸变校正、重投影、图层合成和显示输出。OpenXR 的典型循环把应用和 runtime 分成两个角色：应用生成内容，runtime 负责设备时间、追踪、合成和显示节奏。
下面的图把贯穿场景中的一帧拆成可追踪路径。它只描述延迟判断所需的关键节点，不展开每个平台内部调度细节。
这条路径中，应用可直接控制的主要阶段是 simulation update、resource update、command recording、GPU render 和 frame submit。runtime 可控制的主要阶段是 tracking fusion、prediction、compositor scheduling、lens distortion、timewarp、spacewarp、display timing 和平台级 throttling。优化动作需要落到角色边界：应用把姿态写得更晚、把 GPU 工作做得更稳、把 depth 和 motion vector 等辅助数据提供给 compositor；runtime 利用最新 tracking 数据修正最终图像。
一个 OpenXR 风格的最小循环可以写成下面的伪代码。它展示的是时序关系，省略错误处理、swapchain acquire/release 和多 view 数组管理。
// Pseudocode: frame timing path for one XR frame.
XrFrameState frameState = WaitFrame(session);
BeginFrame(session);
XrTime displayTime = frameState.predictedDisplayTime;
ViewPose views = LocateViews(session, referenceSpace, displayTime);
InputState input = SyncAndReadInput(session, displayTime);
UpdateSimulation(input, displayTime);
BindViewProjectionLate(views);
RenderSceneToSwapchain(views);
SubmitCompositionLayers(session, displayTime);
EndFrame(session);
这段伪代码说明三条延迟原则。第一，view pose 与 input state 应围绕同一个目标显示时间组织，减少状态混用。第二，simulation 可以较早更新，但 view/projection constant buffer 的最终写入应靠近 draw call，这就是 late latching 的工程动机。第三，提交给 compositor 的 layer 要保留足够信息，让 runtime 能在显示前用新姿态做最后修正。
Prediction 是对未来显示时刻姿态的估计。它的输入通常来自 IMU、摄像头追踪、控制器追踪、历史速度和滤波状态；输出是显示时间点的 head pose、eye pose 或 view matrix。预测降低延迟的方式是把应用渲染目标从“当前姿态”移动到“预计被用户看到时的姿态”。在半透明控制面板场景中，应用用预测后的 head pose 渲染墙面 UI，用户在显示时刻看到的面板位置就更接近真实墙面位置。
Late latching 是把姿态或 view/projection 数据的绑定推迟到 GPU draw 前的策略。传统渲染可能在 frame update 一开始就计算相机矩阵，然后后续经历动画、culling、command recording 和 GPU 排队。XR 中，这会让矩阵携带较旧的姿态。late latching 的稳定做法是把 object simulation、visibility、material 准备与最终 view 数据分开；在 draw call 或 command buffer 接近提交时刷新 per-eye view/projection constant buffer。
Timewarp / reprojection 是 compositor 在应用提交后继续修正头动误差的策略。应用已经渲染完上一帧图像后，runtime 可以读取最新 head pose，把图像按新的旋转或位置关系重新采样到当前显示姿态。它降低的是提交到扫描之间的 residual latency。对旋转头动，timewarp 通常效果清晰；对大幅平移、近距离遮挡和新暴露区域，runtime 需要 depth、motion vector 或 frame synthesis 才能得到更稳定的结果。
Foveated rendering 主要降低渲染负载，也能间接帮助延迟。眼动聚焦区域清晰、周边降采样后，fragment shading、带宽和 post process 成本下降，应用更容易在 90 Hz 或 120 Hz 的 frame budget 内完成。这个策略对延迟的贡献来自稳定 frame pacing。眼动数据本身也有延迟，foveated region 的 temporal smoothing 需要和 head pose prediction 分开评估。
Frame pacing 是把每帧工作稳定放入刷新节奏。90 Hz 的单帧槽约为 11.11 ms，120 Hz 约为 8.33 ms。XR 应用在这些槽内还要预留 runtime compositor、GPU queue、display scanout 和 tracking 更新空间，因此应用 GPU time 的目标通常低于完整刷新间隔。高平均帧率不能代表舒适，稳定提交间隔和低 missed frame 更能说明体验。
本节的优化顺序是：先让应用稳定命中目标 refresh slot；再把 view/projection 写入点后移；接着提供 depth、motion vector 或平台要求的 layer metadata 支持 compositor；最后用 runtime metrics 验证 reprojection 与 dropped frame 是否下降。这个顺序把性能优化和姿态正确性连到同一条帧路径上。
143.3 异步时间扭曲（Asynchronous Time Warp）
异步时间扭曲（Asynchronous Time Warp，ATW）是在应用渲染线程之外，由 runtime compositor 使用最新头部姿态对已渲染图像进行再投影的机制。它的输入是上一张或当前已提交的 eye image、原始渲染姿态、最新预测显示姿态、镜头畸变参数和显示时间；输出是更贴近当前头部方向的最终显示图像。这里的“异步”指合成修正可在应用渲染节奏之外运行。
ATW 的价值来自一个时间窗口：应用提交 layer 到显示扫描之间仍然会发生头动。应用在 submit 前拿到的 pose 已经是预测值，但在快速转头时，预测与真实显示时刻仍会存在残差。compositor 如果在更靠近 scanout 的时刻读取最新 tracking 数据，就能对图像做一次更晚的旋转修正。这个动作不会降低应用 GPU render time，却能降低用户看到的姿态误差。
把贯穿场景放入 ATW：用户头向右转动，应用已经按预测姿态渲染出墙面面板。提交后，头又继续转了一小段角度。compositor 根据新的 head pose 计算从旧视图到新视图的重投影矩阵，对左右眼图像重新采样。最终显示中，面板位置更接近真实墙面位置，边缘拖动感下降。
ATW 的基本矩阵关系可以理解为：先把旧图像看成由旧 view-projection 生成，再估计新 view-projection 下屏幕采样点应来自旧图像哪里。工程实现会考虑镜头畸变、per-eye projection、深度信息、隐藏区域网格和显示扫描时序。对读者而言，关键判断是输入空间要一致：旧帧的 pose、当前 pose、projection、eye index 和 layer transform 必须能被 runtime 正确关联。
ATW 的失败信号主要来自信息不足。纯旋转修正可以用 2D 图像重采样近似，近距离物体的大幅平移会暴露 occlusion hole；透明 UI 与真实世界 passthrough 叠加时，旧帧颜色无法提供新露出的背景；动态物体如果没有 motion vector，空间位置会被当作静态表面处理。用户看到的现象通常是边缘拉伸、局部撕裂、遮挡错位或文字变形。
ATW 对提交时机很敏感。应用提交过晚时，compositor 缺少足够时间完成重投影和显示准备；应用提交过早时，渲染使用的 pose 与显示时间距离增大，ATW 需要修正更大的残差。稳定做法是让应用跟随 runtime frame pacing，按 runtime 给出的 predicted display time 组织渲染，并在 GPU 工作量可控的前提下尽量缩短 pose 写入到 submit 的时间。
验证 ATW 是否正在帮助体验，应观察三个层级。第一层是应用是否持续命中 frame budget，GPU time 和 CPU submit 是否稳定。第二层是 runtime 的 reprojection 或 timewarp 指标是否保持低峰值，峰值是否与快速头动同步。第三层是视觉观察：在头部快速 yaw 时，世界锁定面板边缘是否保持稳定，文字是否出现形变，遮挡边界是否产生拉伸。
ATW 也会带来一个判断边界：它能掩盖部分 head pose 残差，无法替应用生成真实缺失几何。应用仍要控制 shader cost、draw count、depth quality 和 frame pacing。把 ATW 当作兜底机制时，舒适性会依赖 compositor 长期补偿；把 ATW 当作最后一段姿态校正时，系统会在负载波动时保持更高稳定性。
143.4 预测与补偿机制的实现技巧
预测与补偿要分层实现。pose prediction 解决“用哪个未来姿态渲染”；late latching 解决“这个姿态何时写入 GPU 可见资源”；spacewarp / frame synthesis 解决“应用缺帧时如何合成中间帧”；motion vector 和 depth 解决“合成时如何理解像素运动和遮挡”。这些机制叠加后，延迟优化才覆盖 head motion、object motion 和 display timing。
Pose prediction 的工程输入应按时间戳管理。应用读取 head pose、controller pose、hand tracking 和 eye gaze 时，需要明确这些数据对应的 runtime timepoint。OpenXR 的 XrTime 是 runtime 定义的单调时间，应用不应把系统 wall clock 与 runtime clock 长期绑定。稳定写法是每帧围绕 runtime 提供的 predicted display time 组织定位查询，并用平台提供的时间转换扩展处理外部传感器或音频同步。
Late latching 的实现要控制资源写入边界。CPU 侧可以较早完成 scene update、animation、visibility list 和 material binding，但最终 per-eye view/projection buffer、gaze-dependent foveation center、controller ray matrix 应在 draw 前或 command submit 前刷新。多线程 renderer 中，工作线程可录制大部分 command，主线程在封口前写入 small dynamic buffer 或 push constants。Vulkan、Metal、Direct3D 的具体接口不同，目标一致：让姿态数据成为帧中最晚确定的一组小状态。
预测也会影响 culling。视锥剔除如果使用旧 pose，快速转头时边缘物体可能被剔除掉，timewarp 再修正也无法显示这些物体。XR renderer 通常会给 culling frustum 留出 angular margin，或使用更保守的 visibility set。半透明面板固定在墙面时，UI 本身需要稳定保留；周边装饰、粒子或远景可按优先级降级。这里的成本取舍是增加少量可见集，换取快速头动下更低的 pop-in 风险。
Spacewarp 或 frame synthesis 在应用没有按目标刷新率交付完整帧时合成中间帧。与 ATW 主要修正头部姿态不同，spacewarp 还试图处理场景内容运动。它通常依赖上一帧图像、depth、motion vector、相机运动和平台 runtime 的估计模型。应用侧能做的稳定工作是输出正确的 motion vector、保留 depth 精度、让透明和粒子路径标记清楚，并把合成质量纳入性能指标。
Motion vector 是描述像素或几何在帧间移动方向与距离的数据。TAA、motion blur、upscaling、frame synthesis 和 spacewarp 都可能依赖它。XR 中 motion vector 的坐标语义必须清楚：它对应 per-eye render target、当前 view/projection、上一帧 view/projection 和对象变换。手柄射线、半透明 UI、skinned mesh、particle 和 passthrough layer 都可能产生特殊边界，错误的 motion vector 会让合成帧出现拖影或局部错位。
Depth buffer 对 reprojection 与 hologram stabilization 价值很高。Microsoft 的 Mixed Reality DirectX 文档展示了在渲染当前 holographic frame 时提交 depth buffer，系统可使用 depth 信息做 per-pixel 稳定处理。跨平台看，depth 能帮助 compositor 判断近远遮挡和像素重投影尺度。应用提交 depth 时需要保证格式、坐标范围、near/far、反向 Z 约定和 per-eye slice 与 runtime 约定一致。
补偿机制还要处理透明层与 UI。半透明控制面板如果作为单独 composition layer 提交，runtime 可用更高质量的 layer transform 保持文字清晰；如果它被烘进主场景 render target，timewarp 会把文字和背景一起重采样，细线和小字更容易变形。对 XR UI，工程上常把高频文本、光标、系统面板和 passthrough overlay 交给 compositor layer，主场景保留三维几何和材质光照。
下面是预测与补偿的检查顺序。它可以用于 OpenXR、Unity XR、Unreal XR、Native SDK 或自研 renderer，但具体 API 名称需要按平台替换。
| 检查项 | 应用侧动作 | Runtime / compositor 证据 | 失败信号 |
|---|---|---|---|
| Predicted pose | 用目标显示时间查询 view pose | predicted display time 与 locate time 对齐 | 快速头动时世界漂移 |
| Late latching | draw 前刷新 view/projection 小 buffer | pose age 下降 | 矩阵更新早于 command recording |
| Conservative culling | 给头动留出视锥余量 | 边缘 pop-in 减少 | timewarp 后边缘缺物体 |
| Depth submit | 提交可采样 depth 或平台等价数据 | stabilization / reprojection 质量提升 | 近物边缘拉伸 |
| Motion vector | 输出动态对象运动 | frame synthesis 伪影降低 | 动态物体拖影、ghosting |
| Layer split | UI 和 passthrough 使用合适 layer | 文字更稳、合成边界清楚 | 小字随背景一起扭曲 |
本节的关键边界是：预测与补偿使用的是估计数据。它们能降低感知误差，也会在输入数据错误时放大伪影。工程实现中，优先保证时间戳一致、坐标空间一致、per-eye 资源一致，再追求更激进的合成策略。任何补偿机制都应配套可关开关和 debug overlay，让团队能比较 raw render、late latch、timewarp、spacewarp 和 depth-assisted reprojection 的差异。
143.5 Motion-to-Photon Evidence and Comfort Risk Evaluation
Motion-to-photon 评估要把体验风险拆成可观察证据。单看平均 FPS 会漏掉两类 XR 问题：一类是帧率达标但姿态太旧，另一类是帧率看似稳定但 compositor 长期依赖重投影。证据链需要同时覆盖应用帧耗时、runtime 合成、显示节奏、追踪状态和用户反馈。
一个可复用的 evidence map 可从五个时间点开始：input sample time、pose prediction time、GPU submit time、compositor latch time、display scanout time。应用不一定能直接读到所有时间点，但可以通过 runtime statistics、profiler marker、GPU timestamp、engine frame timing 和平台 performance overlay 拼出相对关系。目标是判断“旧姿态从哪里进入最终图像”。
| 指标 | 回答的问题 | 健康信号 | 风险信号 |
|---|---|---|---|
| Motion-to-photon | 运动到显示总延迟是否受控 | 峰值少、快速头动时稳定 | 峰值与眩晕反馈同步 |
| App CPU time | 主线程是否拖慢提交 | command recording 稳定 | simulation、culling、GC 抖动 |
| App GPU time | 渲染是否命中预算 | 每帧低于平台预算 | 后处理、透明、阴影尖峰 |
| Reprojection rate | compositor 补偿比例 | 只在瞬时负载出现小峰 | 长时间高比例运行 |
| Dropped frame | 是否错过刷新槽 | 偶发且可解释 | 连续 missed vsync |
| Pose age | 参与渲染的姿态是否新 | late latch 后下降 | 矩阵更新过早 |
| Tracking validity | 姿态数据是否可信 | pose confidence 稳定 | 丢失定位、重定位跳变 |
| User feedback | 指标是否转成不适 | 指标尖峰无主观症状 | 眼疲劳、恶心、方向感错乱 |
舒适风险评估应按场景敏感度分层。静态全景查看器对交互反馈要求较低，但对头动滞后极敏感；手部近距离操作对 controller-to-photon 与遮挡稳定敏感；AR passthrough 对真实世界和虚拟覆盖物对齐敏感；远程渲染还要叠加网络抖动、编码、解码和预测窗口。半透明控制面板属于高敏感 UI 场景，因为小字、直线边缘、手柄射线和世界锁定共同放大延迟感知。
评估一次延迟优化，不应只比较开启前后的平均帧率。稳定流程是先构造固定动作：用户站定、头部做左右 yaw、手柄划过按钮、视线停留在面板文字上；再记录 frame timing、GPU time、reprojection、dropped frame、tracking validity 和主观反馈；然后分别打开 late latching、depth submit、foveated rendering、spacewarp 或 layer split；最后比较指标峰值和视觉伪影。这样能判断每个机制改变的是哪段数据路径。
舒适风险还需要关注连续暴露时间。一次 200 ms 的 dropped frame 可能被用户察觉但很快恢复；持续 20 秒的高 reprojection rate 会让用户逐渐疲劳。评估报告中应记录峰值、持续时长和发生条件。比如“快速 yaw 时 reprojection rate 短暂上升，停止后 2 帧恢复”与“静止观察 UI 时仍长期重投影”代表完全不同的风险。
下面给出一个面向工程复盘的风险分级。它只用于渲染管线排查，不承担医学判断。
| 风险等级 | 证据组合 | 工程判断 |
|---|---|---|
| 低 | app frame 稳定、reprojection 低、用户无不适 | 当前瓶颈不在 XR 延迟链路 |
| 中 | 快速头动时出现短峰，停止后恢复 | 优先检查 late latch、culling margin 和 depth |
| 高 | 静止观察仍有 dropped frame 或高 reprojection | 优先降低 GPU cost 与 CPU submit 抖动 |
| 严重 | 指标峰值伴随眩晕、恶心或方向错乱 | 先关闭高风险特效，恢复稳定 frame pacing |
Evidence map 的最后一步是把指标回写到设计约束。若 app GPU time 经常超过 90 Hz budget，就减少透明叠加、降低动态阴影、启用 foveated rendering 或调整后处理分辨率；若 pose age 高，就移动 view/projection 更新点；若 reprojection artifact 集中在近物边缘，就提交 depth、提高 depth 精度或减少近距离高速移动 UI；若交互反馈慢，就把 input sample、simulation update 和 visual feedback 的时间戳对齐。
本章最终建立的理解是：XR 延迟优化是一个跨 sensor、runtime、application、GPU、compositor 和 display 的证据闭环。prediction、late latching、timewarp、spacewarp、foveated rendering、depth submit 和 frame pacing 都服务同一目标：让用户在目标显示时刻看到与当前身体感知一致的图像，并在失败时能用指标定位风险来源。
最小自检任务
你正在排查一个 90 Hz VR 场景：用户快速左右转头时，房间墙面上的半透明控制面板会短暂漂移；GPU profiler 显示主场景渲染大多数帧为 7 ms，偶尔后处理峰值到 10.5 ms；runtime overlay 显示快速头动时 reprojection rate 上升，静止时恢复正常；手柄按钮高亮没有明显滞后。请判断最可能的延迟链路问题，并给出不依赖特定厂商工具的排查顺序。
答案要点
这个现象首先指向 head motion 到显示链路，而非手柄交互链路。按钮高亮没有明显滞后，说明 controller input 到 visual feedback 当前并非主导问题；漂移发生在快速头动时，说明 prediction error、late pose binding、timewarp 残差或 frame pacing 峰值更值得优先检查。
排查顺序应从 frame pacing 开始。90 Hz 的单帧槽约为 11.11 ms，10.5 ms 的后处理峰值已经接近完整刷新槽，runtime compositor、GPU queue 和显示准备还需要时间，因此这些峰值可能触发 reprojection 上升。先给后处理加 GPU timestamp 或 engine marker，确认峰值是否与漂移时间对齐；若对齐，先降低后处理成本或分辨率，观察 dropped frame 与 reprojection 是否下降。
第二步检查 pose 写入时机。确认 view/projection buffer、per-eye constants 和 UI layer transform 是否在 draw call 前或 command submit 前刷新。若矩阵在 frame update 一开始写入，快速头动会让面板使用较旧姿态。将最终 view/projection 写入移动到更晚阶段，并记录 pose age 或等价指标。
第三步检查 compositor 可用信息。半透明控制面板含有小字和直线边缘，若它被主场景 render target 一起重投影，timewarp 峰值时更容易出现文字扭曲。可比较 UI 作为独立 composition layer 与主场景混合渲染两种路径；同时检查 depth 提交、near/far、per-eye slice 与平台约定是否一致。
第四步检查 culling margin 和视野边缘。快速左右转头时，如果面板或周边几何使用旧 pose 做剔除，timewarp 后可能出现边缘缺失或 pop-in。给 world-locked UI 和近距离几何增加保守可见范围，再观察漂移与边缘伪影是否下降。
核心结论是：当前优先级应是稳定 90 Hz frame pacing、后移姿态绑定、提高 compositor 的 depth/layer 信息质量，再看 reprojection 峰值和用户主观反馈是否同步下降。若静止时指标恢复正常，说明基础追踪和交互路径大概率可用，快速头动路径才是主导风险。
本章知识点总结
- 总延迟链：Motion-to-photon 覆盖姿态采样、预测、应用渲染、runtime 合成、显示扫描和面板响应。
- 感知风险：XR 延迟会破坏视觉与前庭的一致性，头动滞后比普通输入延迟更容易引发不适。
- 预测时间：应用应围绕目标显示时刻查询姿态和输入，减少旧状态进入最终图像的概率。
- 帧生命周期：XR 一帧应按 runtime pacing 组织，从预测显示时间进入渲染，再提交给 compositor 合成。
- Late latching：姿态相关的小 buffer 应靠近 draw 或 submit 更新，降低 pose age。
- Timewarp：ATW 使用最新头部姿态重投影已提交图像，主要降低提交后到显示前的姿态残差。
- 失败边界：重投影无法凭空恢复缺失几何，近距离遮挡、透明层和动态物体更容易产生伪影。
- Depth 价值：高质量 depth 能帮助 compositor 做 per-pixel 稳定与遮挡判断。
- Motion vector：合成中间帧需要可靠运动信息，动态物体和透明对象需要单独检查。
- Layer split：XR UI、文字和 passthrough overlay 常适合独立 layer，以提升合成稳定性。
- Frame pacing：稳定命中刷新槽比平均 FPS 更能解释 XR 舒适性。
- 证据闭环：reprojection rate、dropped frame、pose age、tracking validity 和用户反馈应一起用于舒适风险评估。