探索CSS的本质
前言
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
一文所想到的一种底层交互模型;
模拟代码
1 | import { PaintOperator } from '@/types/css-gl' |
解析代码就是上面这些,由于底层代码做了抽象,所以大部分代码都是生成PaintOperator
对象的;可以看下预设的着色器代码:
1 | precision highp float; // 高精度 |
1 | precision highp float; // 高精度 |
由于模型本身很简单,因此对应的着色器也很简单;通过着色器代码不难看出,我所理解的底层着色器接收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
就知道了:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26void 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
:管理图元绘制风格相关的状态;
后话
事实上,还有很多感兴趣和有疑问的地方没有来得及探究,每一个点都需要时间来找资料和验证;比如一个DOM
结点最终到底可以分为多少层矩形来进行绘制?圆角矩形及渐变色如何在着色器中进行高效的绘制等等,这些都是很有意思的,以后也得找时间研究一下。
相关文档
- How Blink works - Google 文档:一个关于
Blink
渲染引擎的超强概述 - Web IDL 简介 | 澪同学的博客
- https://www.chromium.org/blink
- 再见,CSS Shader (CSS Custom Filter) | 花嫁達の部屋:无意中发现的一个被废弃的规范
- W3C CSS规范主页
- https://www.chromium.org/developers/design-documents/graphics-and-skia :Chromium项目关于Skia使用的概述
- Skia Vulkan Performance - 知乎
- 着色器 - LearnOpenGL-CN