![]()
前言
CSS，全称为Cascading Style Sheets，用于定制文档样式；CSS使得网页的呈现更加丰富，这也是初学前端的人最感到新奇的地方；
但是随着对CSS的深入使用才会发现：那些被我们津津乐道的“xx属性的奇淫技巧”这类东西都只不过是浮在CSS最表层的现象而已；这种对于CSS的使用方式在我看来无异于“盲人摸象”，即只能通过观察表面现象来总结使用方法，而不是从本质出发寻找解决方案，因此就可能会陷入永远只能借助表面现象来解决问题的困境。
关于CSS的定位
在初步了解过浏览器关于网页渲染的机制和原理后，心里有个疑问变得更加突出了，那就是——“CSS在网页渲染中的定位是什么”；我结合了webGL这种单纯的图形渲染API中的图形渲染流程和CSS代码在浏览器中解析后在网页渲染中的作用，得出了一个自己的结论：
CSS是一个用于结构化描述渲染信息的辅助性DSL。
得出这么一个结论主要是基于以下理由：
结构化描述：CSS代码可以解析成CSSOM，然后依附于DOM上，这个得益于CSS语法本身就是键值对式的对象描述这一特性；
辅助性：单独的CSS代码并不能绘制出任何有效的图形，它必须结合HTML解析得到的布局、位置等结点信息才能进行绘制；即CSS代码在渲染过程中并不充当着骨架的作用，更多地是基于骨架赋予更多样的绘制；
DSL：这个就无需多说了，CSS语言本身就不是一门通用性编程语言，它仅仅是针对网页文档的渲染而已，其作用范围与GLSL/HLSL这类着色器编程语言相比简直就是专一得不能再专一了。
CSS与绘制
既然CSS只是辅助渲染的，那么CSS所携带的样式信息又是如何转化成底层的绘制语句呢？
![]()
这里就需要涉及到更详细的浏览器渲染管线流程了，因为光从上图[1]这种大概的pipeline，我们根本无法理解CSS这种字符串信息是如何在浏览器内部进行解析然后转换成具体的底层绘制命令的。不过好在Google内部发表了一个极为详细的演讲稿来阐述网页中的像素是在经历了一个怎样的pipeline之后才显示的：Life of a Pixel（这篇演讲稿当然是极力推荐阅读的）；多亏了这个演讲稿，我终于不用去从Chromium项目源码中去一点点查找CSS渲染的蛛丝马迹了……
![]()
上图是我根据上述演讲PPT和自己的理解所总结的一个渲染pipeline，看似很完整，但是实际上并不是浏览器所有的渲染pipeline，这仅仅是一个初步的流程，后续的优化渲染流程还没涉及；由于后面的优化渲染pipeline和更新渲染pipeline比较复杂，以后再单独研究，这里总结的流程权当是一个简单的全量渲染pipeline；
模拟CSS渲染
如果真要模拟上述流程图中所有pipeline，即HTMl + CSS → 像素，那真是一个巨大的工程，实在是有心无力；我最感兴趣的部分实际上是光栅化的部分，即Paint Operator → 像素，因此基于webGL对这个光栅化做了一个最简化模型：
![]()
可以看到这个渲染pipeline是十足的简单，IMGUI + 全量式绘制；因为我只想验证所谓的Paint Operator携带的绘制信息到底是如何传入到真正的底层——即着色器内的，我想知道着色器内部是如何消化和理解Paint Operator的；所以上面这个模型只是我个人根据Life of a Pixel一文所想到的一种底层交互模型；
模拟代码
import { PaintOperator } from '@/types/css-gl'
import { vec2, vec4 } from 'gl-matrix'
(() => {
const { CSSGL } = WebGLEngine // WebGLEngine是自己手写的一个webGL渲染库
const ops: PaintOperator[] = new Array(50).fill(0).map((val, idx) => {
const randomPos: vec2 = [
Math.random() * window.innerWidth,
Math.random() * window.innerHeight
]
const randomSize = vec2.create()
const randomBg: vec4 = [
Math.random(),
Math.random(),
Math.random(),
1.0
]
vec2.random(randomSize, 200)
return {
id: idx,
shape: {
pos: randomPos,
size: randomSize
},
flags: {
background: randomBg
}
}
}) // 随机构建50个PaintOperator对象
const gl = new CSSGL('test', ops) // 解析PaintOperator数据
gl.paint() // 执行绘制
})()
解析代码就是上面这些，由于底层代码做了抽象，所以大部分代码都是生成PaintOperator对象的；可以看下预设的着色器代码：
precision highp float; // 高精度
uniform vec2 u_Screen; // 屏幕尺寸
attribute vec2 a_Pos; // 顶点坐标
vec2 widthRange = vec2(0.0, u_Screen.x);
vec2 heightRange = vec2(0.0, u_Screen.y);
vec2 outputRange = vec2(-1.0, 1.0); // NDC坐标范围为[-1, 1]
// 将一个值从原来的范围等比映射到另一个范围
float rangeMap (float source, vec2 sourceRange, vec2 targetRange) {
float bais = source / (sourceRange.y - sourceRange.x); // 在范围长度中的占比
float target = bais * (targetRange.y - targetRange.x) + targetRange.x;
return target;
}
void main() {
gl_Position = vec4(
rangeMap(a_Pos.x, widthRange, outputRange),
rangeMap(a_Pos.y, heightRange, outputRange) * -1.0, // 转换成NDC时y轴需要翻转
1.0,
1.0
);
}
precision highp float; // 高精度
uniform vec2 u_Screen; // 屏幕尺寸
uniform vec4 u_Background; // 背景色
void main() {
gl_FragColor = u_Background;
}
由于模型本身很简单，因此对应的着色器也很简单；通过着色器代码不难看出，我所理解的底层着色器接收Paint Operator信息就是通过内置的属性来一一对应，是最原始的方式；
关于Skia
上面这个模拟思路其实很简单，所以我也很想去验证这种思路跟具体的Chrome/Chromium底层绘制有啥不同（单纯的感兴趣）；由于Chromium内部几乎所有的图形绘制都交给了Skia图形库，所以只能去Skia源码去查找蛛丝马迹了；
不过看了一圈Skia项目源码之后，我发现Skia项目实在是太高度抽象了，层层嵌套，从着色器代码里面压根找不出蛛丝马迹，因为着色器代码里面的信息看起来都是很抽象/通用的数据，无法直接联系到图元绘制；看来需要较长的时间才能找出我想要的答案，虽然有点遗憾，但是也从Skia本身发现了一些不错的地方：
Skia内部设计了一个着色器语言，名为SkSL (Skia Shading Language)；SkSL实际上就是基于某一固定版本的GLSL语法进行设计的，其作用应该是抹去不同GPU驱动API着色器语法的差异，以便对于不同的GPU驱动可以进一步输出为目标着色器语言，因此SkSL可以看做是着色器预编译语言[2]；
![]()
Skia的API风格也很有意思，与Canvas API很相似，看一下官网的Demo就知道了：
void draw(SkCanvas* canvas) {
canvas->drawColor(SK_ColorWHITE);
SkPaint paint;
paint.setStyle(SkPaint::kFill_Style);
paint.setAntiAlias(true);
paint.setStrokeWidth(4);
paint.setColor(0xff4285F4);
SkRect rect = SkRect::MakeXYWH(10, 10, 100, 160);
canvas->drawRect(rect, paint);
SkRRect oval;
oval.setOval(rect);
oval.offset(40, 80);
paint.setColor(0xffDB4437);
canvas->drawRRect(oval, paint);
paint.setColor(0xff0F9D58);
canvas->drawCircle(180, 50, 25, paint);
rect.offset(80, 50);
paint.setColor(0xffF4B400);
paint.setStyle(SkPaint::kStroke_Style);
canvas->drawRoundRect(rect, 10, 10, paint);
}
熟悉的命令式以及图元绘制命名；
Skia中有三大基类：SkCanvas、SkBitmap和SkPaint[3]；
SkCanvas：管理绘制相关的API；
SkBitmap：管理bit数据；
SkPaint：管理图元绘制风格相关的状态；
相关文档
How Blink works - Google 文档：一个关于Blink渲染引擎的超强概述
https://docs.google.com/document/d/1aitSOucL0VHZa9Z2vbRJSyAIsAz24kX8LFByQ5xQnUg/edit
Web IDL 简介 | 澪同学的博客
https://blog.ihomura.cn/2019/07/29/Web-IDL-简介/
https://www.chromium.org/blink
https://www.chromium.org/blink
再见，CSS Shader (CSS Custom Filter) | 花嫁達の部屋：无意中发现的一个被废弃的规范
https://blog.mottomo.moe/categories/Tech/zh/2015-09-17-Goodbye-CSS-Shaders/
W3C CSS规范主页
https://www.w3.org/Style/CSS/
Chromium项目关于Skia使用的概述
https://www.chromium.org/developers/design-documents/graphics-and-skia
Skia Vulkan Performance - 知乎
https://zhuanlan.zhihu.com/p/37640688
着色器 - LearnOpenGL-CN
https://learnopengl-cn.readthedocs.io/zh/latest/01 Getting started/05 Shaders/
![]()
