测试环境
Windows 桌面，WinForms + OpenTK (OpenGL 3.3)。
处理器 Intel(R) Core(TM) i9-14900HX (2.20 GHz)
机带 RAM 32.0 GB (31.7 GB 可用)
系统类型 64 位操作系统, 基于 x64 的处理器
操作系统版本 Windows 11 家庭中文版
实现原理
核心思路是：用 C# 承载页面，用 Three.js 组织 3D 场景，用 WebGL 做底层 GPU 绘制。
整体如下：
-
WPF窗口中嵌入WebView2。 -
在 C# 中动态拼接 HTML，并通过
NavigateToString注入页面。 -
页面侧加载
three.min.js，创建Scene / Camera / WebGLRenderer。 -
粒子通过
THREE.BufferGeometry与多个BufferAttribute存储。 -
每帧在 JS 中更新粒子位置与生命周期，提交属性更新后由 GPU 渲染。
-
页面每秒统计一次 FPS，通过
window.chrome.webview.postMessage(...)回传给 C#，在 UI 上实时显示。
总结为：这是一个“CPU 负责粒子状态更新，GPU 负责大规模点精灵绘制”的混合型架构。
关键技术点
- 跨技术栈集成：WPF 与 Web 3D 的桥接
-
C# 端调用
EnsureCoreWebView2Async()初始化浏览器内核。 -
使用
WebMessageReceived接收前端消息，把 FPS 同步回桌面 UI。 -
这样可以让原生桌面应用拥有 WebGL 渲染能力，同时保留 WPF 的业务壳层。
- 大规模粒子数据结构：BufferGeometry
-
粒子位置、颜色、尺寸、生命周期都以
Float32Array组织。 -
通过
geometry.setAttribute(...)绑定到 GPU 可消费的缓冲属性。 -
相比逐对象管理，结构化数组 + 批量绘制是海量粒子的基础。
- 自定义 Shader：粒子视觉在 GPU 完成
-
顶点着色器负责点大小透视缩放、生命周期透明度系数计算。
-
片段着色器利用
gl_PointCoord裁剪圆形粒子并做柔和边缘。 -
材质配置启用
AdditiveBlending，形成更亮的粒子叠加效果。
仿真更新模型：每帧 CPU 循环
当前粒子运动（重力、阻力、边界反弹、重生）都在 JS for 循环中执行。
这使逻辑直观易控，但也带来一个关键瓶颈：**粒子数线性增长时，CPU 计算和属性回写成本同步上升。
核心代码
1. **粒子总量入口**
- `private const int ParticleCount = 100000;` - 这是压测的直接控制阀，影响所有数组长度和每帧循环规模。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 万到 10 万仍能跑得动？
-
WebGL 批量绘制能力较强，点精灵渲染天然适合并行。
-
数据结构使用
BufferGeometry，减少了对象级 draw call。 -
Shader 逻辑相对轻量，没有复杂纹理采样或后处理。
- 为什么到 50 万、100 万会急剧下滑？
核心原因不是“GPU 不能画点”，而是CPU + 数据传输 + GPU 渲染三者叠加后的总成本爆炸：
-
CPU O(N) 更新成本：每帧遍历所有粒子，计算速度、位置、碰撞、重生。
-
缓冲更新成本：
position/lifetime每帧都标记needsUpdate，意味着大体量数据频繁上传。 -
像素填充压力：粒子数量增大后，叠加混合（Additive）会显著增加片段处理负担。
-
浏览器容器开销：WebView2 本质是嵌入式浏览器，不是纯原生图形管线，存在额外调度成本。
- 从数据看当前实现的可用区间
-
推荐实时区间：1 万 ~ 10 万（视业务目标而定）。
-
风险区间：>10 万 后帧率明显衰减，尤其在复杂效果叠加时。
-
极限演示区间：几十万到百万可以“展示数量级”，但不适合交互型实时动画。
总结
-
它验证了
WebView2 + Three.js + WebGL路线在桌面应用中的可行性。 -
它给出了当前实现的性能基线：10 万以内可用，数十万后显著下降，百万级不可实时。
-
它说明了后续优化的重点不只是“继续堆 GPU”，而是要系统处理CPU 更新模型与数据上传路径。
从这个演示效果，我们看到three.js的性能仅仅是opentk(opengl)的1/10 , 可以看出来明显的区别：
