一边是 WebGPU 视觉革命，一边是浏览器垄断争议：Canvas UI 发布 35 个组件

作者 ｜ Daniel Curtis

译者 ｜ 田橙

Canvas UI 是由 React Bits 作者 David Haz 推出的一款开源组件库。它是首个基于实验性 HTML-in-Canvas API 构建的组件库，可以在真实、可交互的页面内容上运行 GPU 特效。

该组件库提供了 35 个组件，包括由指针驱动的流体、火焰、玻璃透镜、ASCII 滤镜、VHS 颗粒和粒子显现效果。每种效果都提供使用 GLSL 实现的 WebGL 版本，以及通过 vgpu 使用 WGSL 实现的 WebGPU 版本，并为 React、Solid、Preact、Vue 和 Svelte 提供封装，同时还支持无依赖的原生 TypeScript。

大多数组件并不是绘制一张静态位图，而是使用 Chrome 的html-in-canvasAPI，在 Canvas 中布局实时 DOM，通过drawElementImage捕获内容，将其上传为纹理，再利用着色器进行变形处理。文本仍然可以选择，链接依旧能够点击，内容也会保留在 无障碍树 中。这些组件并非以软件包形式发布，而是通过一个兼容shadcn的注册表，以源代码形式分发：

npx shadcn@latest add @canvas-ui/liquid-react

要获得完整体验，需要在 Chrome 中启用canvas-draw-element标志，或者使用一个 源试用 令牌。该源试用从 Chrome 148 持续到 Chrome 150，并且令牌只能绑定到一个域名。在其他环境中，html-in-canvas特效会回退为普通 GPU 叠加层，或者保持被包裹内容的原样渲染；3D 对象组件则可以在所有环境中运行。

由于代码会被直接复制到项目仓库中，升级时需要重新运行安装命令，并处理本地修改。切换渲染器通常只需将已安装的文件替换为注册表中带有-webgpu后缀的版本，同时添加vgpu和@webgpu/types。项目 文档 还指出，Chrome 150 对texElementImage2D和copyElementImageToTexture的修改不需要迁移，因为内容捕获通过 2D API 完成，纹理上传则使用标准的texImage2D或copyExternalImageToTexture。

shadcn 称这是他们见过的 最令人印象深刻的注册表之一，Chrome for Developers 账号也表示，很高兴看到html-in-canvas为新框架赋能。Flavio Copes 在一篇 详细拆解文章 中称赞了那些并不华丽但十分扎实的工程实现：Liquid 组件离开屏幕可视区域时，会通过IntersectionObserver停止动画循环；它会遵循prefers-reduced-motion设置，并在组件卸载时释放纹理、程序和事件监听器。他建议使用一个足够亮眼的特效，而不是同时堆上六个，并避免在仪表盘、结账流程和文档网站中使用这些效果。

在 Hacker News 上，一名评论者看到演示页面中的提示横幅后，对这种仅限 Google 浏览器使用的能力表示怀疑：

使用 Chrome……但我们不是应该抵制这种可能让 Google“拥抱、扩展再消灭”其他技术的做法吗？ 尽管有这种遗憾而又冷门的担忧——真希望它不是冷门问题——还是要向作者致敬。

另一名用户回应：

标准化流程要求先有实现，之后才能制定标准。WHATWG 相关议题中最近的评论分别来自 Jake Archibald（Mozilla）和 Anne van Kesteren（Apple）。这不是 Google 单方面推动的项目。

WICG 说明文档 中关于无障碍访问的讨论仍在继续，其中包括如何暴露几何信息尚未更新的可绘制子树。

Paper Shaders 提供从 npm 安装的零依赖 Canvas 着色器，但这些着色器只能以纹理形式位于内容后方或周围。同一作者开发的 React Bits 则直接为 DOM 添加动画。Canvas UI 是唯一将页面本身作为着色器输入的方案，这也正是它依赖 Safari 和 Firefox 尚未实现的功能的原因。

该项目采用 MIT 许可证加 Commons Clause，允许商业使用，但不允许转售这些组件。代码仓库 的 Star 数已经超过 4600，组件注册表也已 支持 MCP，允许智能助手通过 shadcn MCP 服务器浏览并安装组件。

https://www.infoq.com/news/2026/09/canvas-ui-webgl/

声明：本文为 InfoQ 翻译，未经许可禁止转载。