Chromium kernel resource loading, analysis and three-tree synthesis (CHROMIUM39)

Every time I try to look at the implementation of the specific logic in chromium kernel, it's time to look at the code and find the logic. Of course, a lot of information on the Internet can be seen, but every time I read this information, I would like to ask: really so? Does the new version of kernel change this logic?

So, in order to let themselves be confused, or to see the source code, a little bit to see the call stack. Then we can understand the principle of kernel on the whole.

Recently looked at chromium kernel, blink kernel part of the load, HTML parsing, and three trees (Dom tree, Render tree, Render Layer tree) The logic of the composition. In this summary, there will be time to continue in-depth study.

>> chromium kernel and blink kernel conceptual differences

Just contact with the chromium project classmate, often have a doubt, browser kernel, chromium kernel and blink kernel What is the difference?

First, to explain, Blink (WebKit's Google Branch) is the rendering kernel, which is part of the chromium kernel. Provides the basic mechanism of loading, parsing and rendering of Web pages, and provides ports for different browser cores to implement.

And chromium kernel is a browser kernel, the browser kernel is a layer of blink packaging and extension of the implementation, chromium kernel not only to provide page loading, parsing, rendering functions, as well as providing tab forward, backward, refresh; multi-Tab management , history and bookmarks, various callback interfaces , and many other tasks . and can realize some functions of blink kernel, such as rendering and so on.

Therefore summed up a sentence: Blink kernel is chromium kernel heart part.

>> loading

In front of the blog, summed up the Web page load live resources download logic. Don't repeat it here.

Summary point: The load of Web resources is step-by, multi-threaded.

Loading process, starting from loading the main resource, and then downloading the entire master resource, form a string (or a few strings), then parse, form a DOM tree, at this time to encounter the need to load the tag, such as IMG, Srcipt, etc., start the corresponding child resource loading process

>>dom parsing

The main resource is downloaded, is the form of a string, and then the string is tagged. Specific analytic grammar can be read on the online article

The three trees, the DOM tree, the Render tree, and the Renderlayer tree are created in parallel, and their creation is parallel to the child resource's loading.

>> three trees corresponding relationship

Dom tree to Rendertree parsing process, you can see the article: Online articles

In the synthesis of Dom trees, HTMLTreeBuilder.cpp is the key object. One method: Htmltreebuilder::constructtree is to build the DOM tree by taking all tokens that were resolved in the previous step.

This is where the string from the Web page is posted to the build stack of the DOM tree:

W/webkit  (7420): Backgroundhtmlparser::appenddecodedbytesw/webkit  (7420): Backgroundhtmlparser:: Pumptokenizer () W/webkit  (7420): Backgroundhtmlparser::sendtokenstomainthread () W/webkit  (7420): Backgroundhtmlparser::p umptokenizer () W/webkit  (7420): Htmldocumentparser:: Didreceiveparsedchunkfrombackgroundparserw/webkit  (7420): Htmldocumentparser::p umppendingspeculations () W/ WebKit  (7420): htmldocumentparser::p rocessparsedchunkfrombackgroundparserw/webkit  (7420): Htmldocumentparser::constructtreefromcompacthtmltokenw/webkit  (7420): Htmltreebuilder::constructtree

The nodes of the DOM tree are the node classes. For logical relationships such as the type of a node and the inheritance of subclasses, you can view the code yourself.

The root node of the Rendertree is the Renderview class, where each node is renderobject. For each node in Rendertree, you can view the code yourself and have a lot of subclasses for RenderObject.

In the Rendertree build, multiple Rendertreebuilder objects are created.

The Renderlayertree node is the Renderlayer object

Here the parts are posted from the formation logic of the Renderlayer:

W/webkit  (5275): Element::attach w/webkit  (5275): Rendertreebuilder::rendertreebuilderw/webkit  (5275) : rendertreebuilder::createrendererforelementifneeded () W/webkit  (5275): Renderobject::setstylew/webkit  ( 5275): Renderblock::styledidchangew/webkit  (5275): Renderlayermodelobject::styledidchangew/webkit  (5275) : Renderlayermodelobject::createlayerw/webkit  (5275): Renderlayer::renderlayer

Renderlayer tree is an important component in the final display of Web pages.

For the three tree formation process, analysis can see the following blog: Online articles

Then, when you have time, go from here and look at the rendering logic of the Web page.

Blink kernel on the Web page download, analysis and the three tree synthesis logic is also more complex, the details of more things. Here's just a summary of the logic I've been reading about this code lately. If there is time later, we should study this piece in depth. See how to manipulate the DOM tree in the kernel (add nodes, or delete them), etc.

Chromium kernel resource loading, analysis and three-tree synthesis (CHROMIUM39)