更底层的操作 (Direct Pixel Manipulation):

1. Canvas 本质上是一个位图画布。开发者通过 JavaScript API（如 fillRect, drawImage, arc, strokeText）直接向画布的像素缓冲区绘制指令。
2. 浏览器不需要为 Canvas 内部的每个图形元素（如一个矩形、一个圆）构建复杂的 DOM 树节点、计算 CSSOM、进行 布局（Layout/Reflow） 或 绘制（Paint） 这些昂贵操作。
3. 结果: 避免了 DOM/CSS 渲染管线中绝大部分开销（尤其是最耗时的布局和绘制阶段）。
4. 更简单的渲染模型:
5. Canvas: 可以看作是一个单一（或少量）的“图层”。开发者负责在每一帧完全控制绘制什么内容以及如何绘制（清除画布 -> 绘制新内容）。浏览器只需要将这个位图缓冲区合成到页面上即可（Composite 阶段）。
6. HTML/CSS: 浏览器需要管理一个庞大的 DOM 树，为每个元素计算样式（Style Calculation），确定它们的大小和位置（Layout/Reflow），决定哪些部分需要重绘（Paint），最后将所有图层合成（Composite）。任何一个元素的改变（尤其是影响布局的属性如 width, height, top, left, display, font-size 等）都可能触发其父元素、兄弟元素甚至整个文档的重新布局（Reflow），以及后续的大量重绘（Repaint）。

更少的“对象”开销:

1. Canvas 绘制的图形（矩形、线条、路径等）不是浏览器需要持续跟踪和管理的独立对象。它们只是画布上的像素。修改一个图形通常意味着在下一帧重新绘制整个场景或相关部分。
2. HTML/CSS 中的每个元素（<div>, <span>, <img> 等）都是一个有状态的 DOM 对象，浏览器需要为其分配内存、维护样式、监听事件、管理层级关系等。元素数量庞大时，内存占用和管理开销显著增加。

GPU 加速的潜力:

1. 现代浏览器会尽可能使用 GPU 来加速 Canvas 的绘制操作，特别是 2D 上下文的常见操作和 WebGL（基于 Canvas 的 3D 上下文）。GPU 极其擅长并行处理像素操作和矩阵变换（旋转、缩放、平移）。
2. 虽然 CSS 变换（Transform）和透明度（Opacity）等属性也能获得 GPU 加速（提升 Composite 阶段效率），但复杂的 CSS 效果（如 box-shadow, border-radius, filter, clip-path）或频繁触发布局（Reflow）的操作，其性能提升远不如 Canvas 在大量图形操作上的优势明显。

更细粒度的控制:

1. Canvas 允许开发者精确控制每一帧的渲染内容。开发者可以选择只重绘发生变化的部分（脏矩形优化），或者利用离屏 Canvas 进行预渲染，避免不必要的重复计算。
2. HTML/CSS 的渲染由浏览器引擎自动管理，开发者对底层渲染过程的控制相对较弱。虽然可以通过 transform, will-change, contain 等属性提示浏览器进行优化，但效果不如 Canvas 直接控制彻底。