Chrome、Firefox等浏览器是如何渲染emoji、canvas与文本的？

通用渲染主流程 #

所有现代浏览器的渲染逻辑都遵循统一的核心管线：

• 首先解析HTML生成DOM树、解析CSS生成CSSOM树，两棵树合并后过滤display: none等不可见节点，生成仅包含可见元素的渲染树
• 布局阶段（也叫重排/Reflow）：遍历渲染树计算每个节点的尺寸、坐标等几何信息
• 绘制阶段：将每个节点的颜色、边框、阴影等视觉属性转换为底层图形库可识别的绘制指令，存入对应图层的绘制列表
• 合成阶段：将所有图层按z轴层级、透明度等属性合并，最终输出到屏幕帧缓冲区

不同内容类型的具体实现 #

文本渲染 #

• Chrome/Chromium 底层依赖Skia二维图形库做文本栅格化，字形解析依赖FreeType，多语言复杂排版（比如CJK混排、阿拉伯文双向排版）由HarfBuzz处理。核心代码存放在源码的//third_party/skia/src/text/、//third_party/blink/renderer/platform/fonts/目录下
• Firefox 渲染引擎Gecko的文本渲染采用Cairo+FreeType+HarfBuzz的组合，Windows平台会优先调用系统DirectWrite接口做字形渲染优化，相关代码在源码的gfx/thebes/、gfx/cairo/目录下
  渲染流程统一为：字体匹配→字形解析→栅格化生成位图/矢量路径→加入绘制队列→和其他内容合并输出

Emoji渲染 #

Emoji本质属于特殊彩色字形，渲染流程和普通文本高度一致，仅在字体匹配、栅格化阶段有特殊处理：

• 字体匹配阶段会优先匹配系统内置彩色emoji字体（比如MacOS的Apple Color Emoji、安卓的Noto Color Emoji），没有匹配到的话会降级使用浏览器内置的fallback emoji字体
• Chrome的emoji匹配逻辑在//third_party/blink/renderer/platform/fonts/font_fallback.cc文件中，原生支持CBDT、COLR、SBIX等多种彩色字形格式
• Firefox的emoji渲染逻辑在gfx/harfbuzz/目录下，针对低分辨率屏幕做了单独的栅格化优化，避免emoji边缘模糊

Canvas渲染 #

Canvas分2D和WebGL两类实现，都支持软硬件渲染两种路径：

• 2D Canvas：Chrome直接基于Skia的2D绘制接口封装W3C Canvas 2D API，相关代码在//third_party/blink/renderer/modules/canvas/canvas2d/目录；Firefox基于Cairo和WebRender实现2D Canvas能力，代码在dom/canvas/目录。2D指令会先存入缓存队列，满帧或者调用ctx.flush()后才会提交到渲染管线
• WebGL Canvas：两类浏览器都会直接将WebGL指令转译为GPU着色器指令，直接在显存中生成纹理，不需要回拷到内存，合成阶段直接和其他图层合并，性能远高于软件渲染路径

如果需要调试本地浏览器的渲染行为，Chrome可以开启chrome://flags/#compositor-layer-debugging查看分层渲染信息，Firefox可以在开发者工具性能面板勾选“绘制闪烁”选项查看实时绘制区域。

内容的提问来源于stack exchange，提问作者hdn