深色模式
性能诊断：先找到慢在哪一步
“播放有点卡”是有效感受，却不是足够的诊断。卡顿可能来自数据解码、等值线提取、几何组合、纹理上传、shader 编译，也可能是透明层的 GPU 填充成本。优化前先把症状限定到可重复的动作。
测量也有精度与误差。先区分精度、误差和容差，再决定记录的数字能支持什么结论。
把一帧拆成可测阶段
CPU 负责准备数据和提交命令，Worker 可以承担独立计算，GPU 负责执行绘制。三者会并行，也会互相等待。60 Hz（赫兹，每秒 60 次刷新）显示的一帧约 16.7 ms（毫秒，1 ms=0.001 s），120 Hz 约 8.3 ms；浏览器所说的 50 ms Long Task 是诊断阈值，不是“低于它就不卡”的标准。
text
交互 → 状态更新 → CPU/Worker处理 → GPU上传 → 绘制 → 显示给这些阶段标记起止，分别记录稳态播放、拖动、暂停交接、首次进入和路由返回。相同数据、相机、窗口尺寸与缓存状态，才能使前后对比有意义。冷启动编译与热态播放应分开报告。
Worker 不能替你消除所有主线程工作
等值线提取移到 Worker 后，主线程仍可能同步构造和组合大量 Primitive。可以先用一个可控的密集场复现，查看性能记录是否集中在几何编码和组合，再尝试异步 Primitive 准备。不要一看卡顿就把算法改成另一套，或把所有步骤都归咎于垃圾回收。
数据传输也有成本。Transferable 可转移 ArrayBuffer 所有权，避免一些复制，但发送方随后不能继续把已分离的缓冲当成有效输入。Worker 并不自动降低 GPU 上传量，也不自动合并绘制命令。
帧数和 GPU 时间不是同一个量
requestAnimationFrame 回调数不等于实际呈现帧数；CPU 提交耗时也不等于 GPU 完成耗时。支持时可使用 GPU 时间查询（timer query），并处理 disjoint（测量时钟失去连续性）等无效结果。同步 readPixels 会改变被测过程，诊断开销应单独说明。
可以做有方向的实验：减少屏幕分辨率后显著变快，提示片元/带宽压力；减少对象数而保持像素量后变快，提示提交或几何准备成本。这些是线索，仍要结合记录验证，而不是直接宣布根因。
风的运动
观察 GPU 更新粒子状态与在地球上的运动。
在浏览器本地运行 · 无需账号 · 鼠标拖动旋转，滚轮缩放
教学合成数据，不代表真实观测或天气预报。规则场用于验证，拟真形态用于观察复杂结构。 数据说明
查看运行源码
此代码直接读取实际运行的实验模块。按 kind 分支定位当前实验，也可查看数据公式和 GLSL。
读取源码…观察任务
比较规则风与拟真风，再旋转和缩放。若只有首次启动停顿，稳态正常，与每次暂停都停顿，排查顺序应相同吗？页面没有超过 50 ms 的任务，是否能保证每个设备 60 FPS？
展开答案
首次停顿先看加载、编译、分配和缓存；每次暂停先看模式交接、几何准备与资源替换。没有 Long Task 仍可能超过单帧预算，或完全受 GPU 限制。结果应附设备、浏览器、画布尺寸与实验条件，不能从一次本机记录推广到所有设备。
阅读依据：Cesium 1.145 Primitive 源码、Khronos EXT_disjoint_timer_query_webgl2。