ChartGPU：用 WebGPU 渲染百万级数据点，图表库的 GPU 化试验
阅读时间: 大约 8 分钟
ChartGPU：用 WebGPU 渲染百万级数据点，图表库的 GPU 化试验
浏览器数据可视化有个老瓶颈：Canvas 2D 和 SVG 本质是 CPU 路径绘制，数据点上到几十万，主线程就开始掉帧。主流方案（ECharts、Plotly）靠 WebGL 扛大数据，但 WebGL 是 2011 年的 API，写起来像在搞图形引擎。WebGPU 是浏览器新一代图形与计算 API，更现代、更适合把计算塞进 GPU。ChartGPU（MIT、零 npm 运行时依赖）就是一个直接押注 WebGPU 的图表库——不做 Canvas/WebGL 回退，专为百万点级时序、流式更新和多图仪表盘设计。本文基于官方 README 实读分析。
一、它瞄准的场景：百万点 + 流式 + 多图共享 GPU
README 开篇就划清了定位：
“ChartGPU renders charts with WebGPU (not Canvas2D or WebGL). It is aimed at: dense time series and multi-million-point series / streaming updates / shared-device multi-chart dashboards / 3D series.”
也就是说它不打算做”通用图表库”和 ECharts 抢市场，而是专攻三个重负载场景：
- 百万级密集时序：首图即官方 100 万数据点散点密度示例——不是逐点画圆点，而是 GPU 分箱成热力图（binSize/colormap/对数归一化可调），这样百万点也能实时缩放平移；
- 流式追加：
appendData(x, y, { maxPoints: 50000 })用环形缓冲 FIFO 滚动，热图和 3D 曲面用专用更新 API，而不是每帧重建整棵配置树； - 多图共享一个 GPU Device：仪表盘里 3 个以上图表时，建一次 adapter/device/pipelineCache 传给每个
ChartGPU.create，避免每图重复初始化 GPU 管线。
上图是官方”APM Streaming Dashboard”示例：延迟（P50/P95/P99 带告警线）、吞吐量、CPU/内存、错误率（异常点标注）、连接池五张图在一块， elapsed 278 秒仍在实时追加——这就是”共享 Device + 环形缓冲”的目标场景。
二、技术机制：CPU 抽稀 + GPU 渲染
性能管线的分工值得注意（README 实读）：
- 采样抽稀：LTTB / min / max 在 CPU 上做；符合条件的折线序列可把抽稀放到 GPU；
- 数据结构：推荐用
Float64Array列式存储（x、y 各一个 TypedArray），小 demo 才用对象/[x,y] 元组——列式布局才能零拷贝喂给 GPU； - 图表类型：line/area/bar/scatter/pie、candlestick/ohlc、heatmap/band/errorBar/impulse，外加
cartesian3d的 pointCloud3d 与 surface3d； - React 绑定：
chartgpu-react已发布。
三、最激进的取舍：没有回退
README 里一句话非常硬：“There is no WebGL/Canvas fallback. Unsupported browsers must be gated by the host app.”——不支持 WebGPU 的浏览器，它连图都不画，必须由宿主应用自己检测 navigator.gpu 并降级。
这意味着：
- 生产可用性被 WebGPU 普及度卡死。 官方在 README 里给了检测样板（
navigator.gpu→ requestAdapter → requestDevice），等于把”什么时候能用”的判断完全甩给宿主； - Koala 点评说得直接：“目前 WebGPU 浏览器兼容性较弱，生产环境还不推荐使用”——WebGPU 在 Chrome/Edge 桌面端支持较好，Safari 与移动端、企业内网老浏览器仍需逐个确认；
- 它换来的是架构简单：不用维护两套渲染路径，所有精力押在 WebGPU 这一条线上。
四、口径与局限
- “百万点”是密度图玩法，不是任意百万点折线。 首图那种百万点是靠 GPU 分箱成热力图才扛得住；真要画一百万条独立折线的路径，浏览器和用户眼睛都受不了——官方也说 eligible line series 才走 GPU 抽稀。
- 没有性能对比基准。 README 宣传目标场景，但没有附和 ECharts/Deck.gl 的 benchmark 数字（仓库里有 benchmarks/ 目录，但博客口径未引用）。“快”目前是架构推断，不是实测对比。
- 生态早期。 仓库只有 3 个 open issue，组件类型还在补齐——饼图、基础图表的交互打磨程度和 ECharts 这种十年库没法比；官方定位也是”大数据场景专用”。
- 学习成本。 要自己管理 GPU adapter/device/pipelineCache、处理 WebGPU 不支持时的降级 UI，集成复杂度远高于
echarts.init。 - 3D 是附赠，不是主力。 pointCloud3d/surface3d 是差异化亮点，但成熟度显然不如 2D 时序。
五、客观评价
优势：
- 架构方向正确：大数据可视化的未来在 GPU，WebGPU 比 WebGL 更现代；
- 零运行时依赖 + MIT，嵌入无负担；
- 流式环形缓冲、共享 Device、GPU 分箱这些都是为”实时监控大屏”量身定做的；
- 列式 TypedArray 接口设计贴近 GPU 友好实践。
局限：
- 无回退策略 = 必须宿主自己做特性检测和降级；
- 生态早期，图表类型与交互打磨不及成熟库；
- WebGPU 普及率是硬约束，2026 年仍不适合面向通用互联网用户的产品；
- 集成成本高于传统图表库。
六、谁该关注
做可观测性仪表盘、金融 K 线大屏、科研可视化、工业监控——这些”数据量巨大 + 用户多在现代 Chrome/Edge 桌面端”的场景，值得把 ChartGPU 作为候选。做面向大众用户的营销页图表、移动端 H5、企业内网老浏览器环境，请继续用 ECharts。它当前更准确的身份是：一个高质量的 WebGPU 图表教学样本 + 特定场景的早期候选，而不是 ECharts 的替代品。