Inside look at modern web browser (part 3)

Render Process的内部工作

Render Process处理tab里的所有东西。有时一部分代码被worker threads来处理，当我们使用service worker or web worker。compositor and raster threads也运行在Render Process中

 

 

Parse

construction of a DOM

当RenderProcess接受到html data，main thread开始解析text string → Document Object Model（DOM）。在html代码写错的时候，生成DOM的算法，可以自动纠正

Preload

html中的css和img之类的外部资源，会提前加载好 

JS can block the parsing

因为JS可以重写html的内容，类似document.write()，所以当解析DOM的过程中，碰到<script>就会先load,parse and execute the js code 

告诉Browser加载资源的规则

例如async,defer，可以让js异步加载，而不block parse dom 

Style calculation 

 

 

 Layout

和DOM Tree长的差不多，但只包含了类似x,y的坐标信。确定layout  tree是个有挑战的事情，字体大小，什么时候换行，都很关键。在chrome，有一个很大的团队在做layout的工作

Paint

有了大小，位置，形状，颜色等等信息。我们还要确定渲染的顺序 

 

 Update rendering pipline is costly

    更新渲染的某一个stage，会导致后面的stage都要重新生成数据。这样的开销是非常大的。

以元素动画为例：

因为这些计算在RenderProcess的主线程，因此可以被JS block。我们可以用Web Workers防止阻塞

Compositing
复合，将图层分为多个layers，并独立光栅化，在需要的时候组合出新的帧。 在chrome first release的时候，是按照viewport有什么就重新光栅化未光栅的内容

同时，在这一步，主线程遍历layout tree并生成layer tree

 

不能每个元素都有一个layer tree node，这样操作数量太大，反而性能下降 

 

raster and composite off the main thread

一旦layer tree和paint order确认了，主线程将这些信息提交到compositor thread。一个layer可能很大，因此compositor thread将layer divides into tiles并且交到raster threads。光栅化线程将数据交给 gpu memory
 

 

 

合成器线程可以对光栅化线程进行优先级排序，因此viewport的内容可以先被渲染

一旦tiles都光栅化完成，合成器线程通过draw quads合成一个帧。然后合成帧通过IPC发给BrowserProcess，再交给GPU Process

A compositor frame is then submitted to the browser process via IPC. At this point, another compositor frame could be added from UI thread for the browser UI change or from other renderer processes for extensions. These compositor frames are sent to the GPU to display it on a screen. If a scroll event comes in, compositor thread creates another compositor frame to be sent to the GPU.
 

 

 

转自《Inside look at modern web browser (part 3)》学习笔记_Conchpeng的博客-CSDN博客