WebRender 渲染过程
Chrome RenderingNG: https://developer.chrome.com/articles/renderingng/
// 如果场景/动画不复杂，用主线程渲染花费的时间也不多
// 没有优化滚动的平滑（之前是 GPU 合成）
解析得到 DOM tree 和 每个 node 的样式后，通过 render 的两部分渲染到屏幕上：
- Layout: combines the HTML and CSS with information like the viewport size to figure out exactly what each element should look like
- Draw: painting and compositing
history(main thread)：
- rectangle invalidation
- layers and compositing
- move to GPU:
- Painting the layers(hard, still has some costs)
- Compositing them together
- took this parallelism even further and added a compositor thread on the CPU
总结：像游戏 3D 渲染引擎一样渲染网页，用 GPU 绘制每帧每个像素，不再使用 CPU painting pixel
Layout details: layers(stacking contexts) …
不需要合成层了
利用 CPU 多核
Layout now gives us a different data structure to render. Before, it was something called a frame tree (or render tree in Chrome). Now, it passes off a display list.
The display list is a set of high-level drawing instructions. It tells us what we need to draw without being specific to any graphics API.
Whenever there’s something new to draw, the main thread gives that display list to the RenderBackend, which is WebRender code that runs on the CPU.
The RenderBackend’s job is to take this list of high-level drawing instructions and convert it to the draw calls that the GPU needs, which are batched together to make them run faster.
Then the RenderBackend will pass those batches off to the compositor thread, which passes them to the GPU.
RenderBackend thread other job:
- Removing any unnecessary shapes from the list (Early culling)
- Minimizing the number of intermediate textures (The render task tree)
- Grouping draw calls together (Batching)
- Reducing pixel shading with opaque and alpha passes (Z-culling)
GPU:
- vertex shading
- rasterization
- pixel shading(can program, texture mapping)
// Current: The CPU still has to do some painting work. For example, we still render the characters (called glyphs) that are used in blocks of text on the CPU.