An Overview of WebCore

转载 2011年01月11日 13:49:00

An Overview of WebCore

WebCore can be divided into two principal areas: KWQ and KHTML.

KWQ - KWQ (pronounced "quack") is an adapter layer used to communicate with KHTML. It is written in Objective C++. The KHTML engine used in Konqueror was written on top of a cross-platform toolkit called Qt. KWQ is essentially an implementation of the subset of Qt required to make KHTML work on OS X. KWQ files can be found under the "kwq" subdirectory.

KHTML - KHTML is the layout engine and contains all of the code for constructing and rendering HTML and XML. This code is written entirely in C++, with the exception of some glue code that communicates with WebKit (using Objective C++). In general, code inside the "khtml" subdirectory is designed to be given back to KDE unless that code is contained in a .mm file (signifying Objective C++ code) or is contained inside #if APPLE_CHANGES.

When you see APPLE_CHANGES in the code, then we have deviated from KHTML to solve some problem unique to OS X, and it makes no sense for those changes to be used when building KHTML on other platforms.


The "khtml" directory contains only seven subdirectories. They are as follows:

  • css - The CSS subdirectory contains the implementation of CSS parsing, the CSS object model, and the code for handling the computation of style on elements. It contains data structure implementations for sheets, rules, declarations, and selectors, as well as for CSS unit types.
  • dom - The DOM subdirectory contains the C++ language bindings for the DOM, both HTML and XML. These language bindings are not used internally by the layout engine, but are instead designed to be used by JavaScript only. Each interface in the DOM specification is represented by a corresponding C++ class that wraps the real implementation of that DOM element. Basically each implementation in this directory serves as a pass through from JS to the real element implementation.
  • ecma - The ecma subdirectory contains the JS glue code that connects JS and the DOM. Whenever a script tries to invoke a method or get/set a property on a JS object that represents a DOM object, the glue code for that object is invoked. The glue code then passes the request through to the DOM code (in the dom subdirectory), which in turn passes the request through to the real implementation. 

    [Script accesses property] -> [JS Object] -> [Ecma Glue Code] -> [DOM Object] -> [DOM Object Implementation]
  • misc - Contains some miscellaneous helper classes used by the rest of the code. The most important object found here is the implementation of KHTML's memory cache in loader.h/.cpp. This cache is designed to hold scripts, stylesheets, and images. Scripts and stylesheets are stored in raw string form and so must still be compiled/parsed even when pulled out of this cache. Images are stored in a decoded form, so that they need not be re-decoded if they are contained in the cache.

    The cache itself uses the LRU-SP (size-adjusted and probability-aware LRU) algorithm for storing objects in memory and scales dynamically based off the amount of memory available on the system.
  • html - Contains the implementation of the HTML DOM, as well as the HTML parser and the HTML tokenizer. The raw HTML data is sent to the parser, which constructs a tree of HTML DOM implementation objects.
  • xml - Contains the implementation of the DOM Core. The HTML implementation objects derive from base class implementations contained in this directory. In addition XML document tree construction is handled here. Parsing is handled over in KWQ using expat, but listeners in this subdirectory build up the tree in response to callbacks from the expat parser.
  • rendering - The implementation of the rendering model for KHTML. Classes in this subdirectory represent rectangles that you actually see on screen (or when printing). They correspond to objects in the DOM and are constructed based off the computed style information for DOM objects.

Example: "Hello World" HTML Document

Consider the following HTML document:




p { color: red }




<p>Hello world.</p>



Let's follow the construction of this document from parsing through to the final rendering on screen. From WebCore's perspective, the action starts in an object called the KHTMLPart. The KHTMLPart is a container object that houses the current document, its JS objects, its render tree, and its stylesheets.

The begin method creates the appropriate document (HTML vs. XML) based off the MIME type sent by the Web server.

The document creates an object called an HTMLTokenizer whose implementation can be found in khtml/html/htmltokenizer.cpp. The tokenizer's job is to scan the bytes sent from the network and construct tokens out of the source. For example it figures out when you have an open tag or a close tag, or what kinds of attributes go with a specific tag.

The tokenizer in turn creates a KHTMLParser. The implementation of the parser can be found in khtml/html/htmlparser.cpp. The parser's job is to take the tokens it receives from the HTML tokenizer and build DOM nodes. The entire construction of the DOM tree for an HTML document happens from within the parser.

When the parser encounters stylesheets such as the one contained in the example above, it creates an instance of a CSS parser to build up a CSS object model for the rules, declarations and selectors contained in the sheet. The implementation of the CSS parser can be found in khtml/css/cssparser.cpp.

As sheets complete construction, they are added to the document. The parsing of a sheet does not delay the construction of the DOM tree by the parser, unless the sheet is contained inline inside the HTML (as in the example above).

As soon as style information becomes available (i.e., all stylesheets have loaded and been attached to the document), style information will be computed for each element. This method, called styleForElement, can be found in khtml/css/cssstyleselector.cpp. This method examines all of the stylesheets in the document and it constructs a RenderStyle object that contains all of the computed style information for a given element in terms that are easily accessible to the render tree.

Once the style information has been computed, if a corresponding rendering object should be constructed, then that render object is built and the style object is attached to the render object (and owned by the render object).

The process of building RenderObjects and RenderStyles for elements is called attachment. Similarly the destruction of said objects is called detachment. All DOM implementation objects have an attach() method that is called recursively to build up the render tree, and a detach method that is called to destroy the render tree.

Once the render tree has been built, it must receive a layout. RenderObjects implement a layout method that is used to determine the position and size of the RenderObject boxes on screen. Layout is a recursive function, so calling layout on the root RenderObject results in the entire rendering tree being flowed.

Finally once all of the rendering objects have been placed at the correct positions, they are painted. All RenderObjects implement paint methods. Painting is also recursive.

So to summarize, the steps involved in building up a document are:

  • HTML Tokenization
  • HTML Parsing
  • Stylesheet Parsing/Construction
  • Document Tree Construction
  • RenderStyle and RenderObject Construction
  • RenderObject Layout
  • RenderObject Painting

Each of these steps will be covered in greater detail in subsequent documents.



转自: 浅谈WebKi谈WebKit之WWebKit之WebCore篇  1、从源代码目录结构来看 WebCore目录主要包括如下目录:bindings 包含将Dom Binding给Javas...
  • leeeryan
  • leeeryan
  • 2011年01月12日 14:18
  • 3418


从上次学习WebKit加载已经过去了大半年了,终于又有时间理一次加载流程。期望逐步完善细节,最后能有一个系统的总结。 首先可以这样理解WebKit的加载逻辑,涉及三个主要的组件, 其中HTTP s...
  • HorkyChen
  • HorkyChen
  • 2014年02月05日 00:07
  • 6176

[Android] 'WebView-- Caught a crash, signum=11'的解决

碰到一个奇怪的问题: WebView在显示本地的一个h5页面时,在Mi 2S可显示,页面上同样属性的按钮有两个可点击,但第三个按钮点击导致Activity必定出现崩溃。崩溃无详细日志,只有如下两句线...
  • sodino
  • sodino
  • 2015年10月29日 11:54
  • 2659

[WebKit] WebCore之页面加载的设计与实现

这里主要分析WebContentProcess中加载页面的过程,主要针对HTTP请求的处理。 主要结构 WebKit2从接受到loadURL开始,就会准备尝试加载网络数据。不同平台用于处理HTTP...
  • bamboolsu
  • bamboolsu
  • 2015年02月06日 12:41
  • 518

Windows Webcore 编译出错

Windows Webcore 编译出错,如下错误。可以把/verbose:lib 看输入的lib都是什么路径的,然后就一一解决。 2>ExecutableAllocatorWin.obj : err...
  • ChenFr
  • ChenFr
  • 2011年03月09日 13:20
  • 795

webkit text width callstack 看了想哭的调用堆栈

* thread #1: tid = 0x1d07, 0x0000000103089b43 WebCore`WebCore::FractionalLayoutSize::width() const +...
  • YAJUN0601
  • YAJUN0601
  • 2012年11月29日 12:06
  • 1561

iOS WebCore的WebEvent和EventHandler

WebEvent是iOS专有的类,负责封装和携带从UIKit得到的系统事件信息,并由WebKit层的WAKResponder子类传递到WebCore的EventHandler。 UIKit层的逻辑可...
  • hursing
  • hursing
  • 2013年06月18日 16:22
  • 3362


在webkit在win32下的编译规则(七)中,曾经说到要专门介绍js binding这部分的,但后面逐渐忘记了,最近有网友提起,特加入js binding这部分的介绍。 首先来说是js engin...
  • chief1985
  • chief1985
  • 2011年09月12日 23:30
  • 9155


  • jiangnanyidiao
  • jiangnanyidiao
  • 2015年03月02日 19:58
  • 868


1、从源代码目录结构来看  WebCore目录主要包括如下目录: bindings 包含将Dom Binding给JavascriptCore方面的代码,同时包含依据idl接口描述文件,自动生成对...
  • xlf13872135090
  • xlf13872135090
  • 2012年10月16日 20:44
  • 1608
您举报文章:An Overview of WebCore