如何利用 GPU Rasterization 硬件加速减少重绘过程中的 CPU 占用

如何利用 GPU Rasterization 硬件加速减少重绘过程中的 CPU 占用的重点在于把前置条件、操作顺序和容易误判的地方分清楚。

能，GPU Rasterization 仅在启用 chrome://flags/#enable-gpu-rasterization 且页面满足图层合成、设备支持等条件时，将光栅化任务从 CPU 卸载至 GPU，从而降低主线程光栅负担。

GPU Rasterization 是什么，它真能降低 CPU 占用？

能，但仅限于特定渲染路径下——当 Chrome（或基于 Chromium 的浏览器）启用 chrome://flags/#enable-gpu-rasterization 且页面满足条件时，原本由 CPU 执行的光栅化（rasterization）工作会交由 GPU 完成，从而显著减少主线程的光栅任务堆积。关键点在于：这不是“打开就生效”的全局开关，而是依赖图层合成策略、设备能力与内容特征的条件触发机制。

哪些元素/场景实际走 GPU Rasterization？

只有被提升为合成图层（composited layer）且满足光栅条件的内容才可能启用 GPU 光栅。常见触发场景包括：

1. 设置了 will-change: transform 或 opacity 的元素（需已触发合成）
2. 使用 transform: translateZ(0) 或 translate3d(0,0,0) 强制提升图层（注意：现代 Chrome 更倾向按需提升，硬加可能反而增加图层数量）
3. CSS filter（如 blur()、drop-shadow()）启用时，对应图层默认启用 GPU 光栅
4. Canvas 2D 上下文在支持 canvas.gpuRasterization 的版本中（需 chrome://flags/#enable-canvas-2d-gpu-rasterization 配合）
5. 滚动容器（如 overflow: scroll）内部内容若形成独立图层，其光栅也倾向 GPU 化

为什么开了 flag 还没看到 CPU 占用下降？

这是最常被忽略的实际瓶颈：GPU Rasterization 不会加速所有绘制环节。以下情况会让它“失效”或“不生效”：

1. 主线程仍在执行大量 JS 计算、样式计算（Recalculate Style）或布局（Layout），光栅只是绘制流水线中的一环
2. 图层未真正合成——用 chrome://render-frame-hosts 或 DevTools 的 Layers 面板确认是否出现 GPU raster 标签，而非仅显示 Raster
3. 启用了 chrome://flags/#disable-gpu-rasterization（优先级高于 enable 开关）
4. 设备不支持：部分集成显卡、旧版 macOS、或启用了 --disable-gpu 启动参数时，GPU 光栅会被静默降级
5. 内容含大量小尺寸、频繁变化的文本或 SVG——这类内容仍由 CPU 光栅处理，因 GPU 光栅更擅长处理大块、静态或缓存友好的图块（tile）

如何验证和微调 GPU Rasterization 是否起效？

别只看 flag 开关，要靠工具链交叉验证：

1. 打开 chrome://gpu，搜索 “Rasterization” —— 确认状态为 Hardware accelerated，且无红色警告
2. 在 DevTools Performance 面板录制重绘过程，过滤 raster 事件：若看到 GPU Raster 类型的长条，且对应主线程 Task 时间明显缩短，说明生效
3. 对比开启前后 chrome://tracing 中的 cc::DirectRasterWorkerPool 和 cc::GpuRasterBufferProvider 调用频次
4. 避免滥用 will-change：过度提升图层会导致内存占用上升、tiling 开销增大，反而拖慢整体帧率

真正影响 CPU 占用的，往往是图层划分合理性与 JS 执行时机，GPU 光栅只是其中一环。它不会修复 layout thrashing，也不能绕过 paint 阶段的样式解析开销。盯着光栅本身优化，容易错过更重的瓶颈。