Three.js + WebGL 粒子动画实测：10 万粒子流畅运行

2. GPU 友好数据准备

• positions / colors / sizes / lifetimes / maxLifetimes 都是 Float32Array。
• BufferAttribute 绑定后由 THREE.Points 进行一次性批量绘制。

3. 渲染材质与 Shader

• THREE.ShaderMaterial({...}) 挂载 vertexShader 与 fragmentShader。
• 开启 transparent + AdditiveBlending + depthWrite:false，确保粒子叠加效果。

4. 每帧更新与提交

• updateParticles(deltaTime) 内遍历全部粒子更新状态。
• 更新后设置：
  • particles.geometry.attributes.position.needsUpdate = true
  • particles.geometry.attributes.lifetime.needsUpdate = true
• 这一步会触发 GPU 侧缓冲同步，粒子越多，带宽与提交压力越大。

5. 桌面侧 FPS 可观测性

• 页面端每秒 postMessage('FPS: ' + fps)。
• C# 侧 WebMessageReceived 更新 txtFPS.Text。
• 这让测试过程具备了稳定的在线观测能力。

实测结果

1 万粒子：FPS 145 , 非常流畅； 10 万粒子：FPS 53 ，流畅； 50 万粒子：FPS 14 ，明显卡顿； 100 万粒子：FPS 7，严重卡顿，接近不可用；

性能分析

1. 为什么 1 万到 10 万仍能跑得动？

• WebGL 批量绘制能力较强，点精灵渲染天然适合并行。
• 数据结构使用 BufferGeometry，减少了对象级 draw call。
• Shader 逻辑相对轻量，没有复杂纹理采样或后处理。

2. 为什么到 50 万、100 万会急剧下滑？

核心原因不是'GPU 不能画点'，而是CPU + 数据传输 + GPU 渲染三者叠加后的总成本爆炸：

• CPU O(N) 更新成本：每帧遍历所有粒子，计算速度、位置、碰撞、重生。
• 缓冲更新成本：position/lifetime 每帧都标记 needsUpdate，意味着大体量数据频繁上传。
• 像素填充压力：粒子数量增大后，叠加混合（Additive）会显著增加片段处理负担。
• 浏览器容器开销：WebView2 本质是嵌入式浏览器，不是纯原生图形管线，存在额外调度成本。

3. 从数据看当前实现的可用区间

• 推荐实时区间：1 万 ~ 10 万（视业务目标而定）。
• 风险区间：>10 万 后帧率明显衰减，尤其在复杂效果叠加时。
• 极限演示区间：几十万到百万可以'展示数量级'，但不适合交互型实时动画。

总结

1. 它验证了 WebView2 + Three.js + WebGL 路线在桌面应用中的可行性。
2. 它给出了当前实现的性能基线：10 万以内可用，数十万后显著下降，百万级不可实时。
3. 它说明了后续优化的重点不只是'继续堆 GPU'，而是要系统处理CPU 更新模型与数据上传路径。