渲染与呈现
到底画了什么、画了几遍，以及最后是谁在合成。
读完这一区，你可以
区分视图、主场景和合成器的职责，为画质与性能问题选择排查方向。
开始之前
先了解会话与参考空间，再进入渲染细节。
建议阅读顺序
渲染与呈现
头显的一帧不是浏览器的一帧。你的场景要按视图画一遍（立体头显是两个视图，有时更多），画进一个由运行时持有的帧缓冲，按运行时定的节奏。然后由一个你控制不了的合成器决定用户实际看到什么、什么时候看到。WebXR 里多数性能上的意外，都来自不知道这条边界在哪儿。
这三篇从不同侧面逼近同一条边界。立体渲染讲的是你这一侧发生的事：为什么每只眼睛需要自己的投影矩阵和视图矩阵、为什么这两者不是简单的平移副本、以及把所有东西画两遍对本来就紧张的帧预算意味着什么。Layers 讲的是把活交回边界另一侧：把一块四边形或者一个柱面的内容交给运行时，让合成器去摆放，而不是你自己把它贴到几何体上。注视点渲染讲的是少为那些你本来就看不清的像素付钱，以及你设的那个数字只是一个请求 —— 运行时可以按自己的方式重新解释它。
贯穿这几篇的是同一件事：合成器不是一个你可以忽略的实现细节。它会做延迟重投影，它接收的内容可以和你主场景不同分辨率，而且它正是「画进 3D 场景里的文字发虚、同样的文字交给 layer 就依然锐利」的原因。判断一个问题落在边界的哪一侧，就已经解决了大半。
按这个顺序读
先读立体渲染。它解释了那个「按视图循环」—— 而 Layers 正是对它的优化，是你试图避免付两遍的那笔成本。
Layers 放第二，因为只有先知道「画进主场景要花多少」，它的价值才看得见。倒过来读，Layers 会显得像一个冷门 API，而不是你刚量出来的那个问题的显然答案。
注视点渲染放最后，因为它是唯一一个「不实测就没有意义」的。它省的是片元着色，所以在一帧卡在绘制调用或者 CPU 上的时候，把强度拉满也什么都不会变。
把概念连起来
选择场景中的一块文字面板，分别考虑几何体贴图和独立图层两种方案。列出清晰度、更新频率、设备支持和测量成本的差异。