Chromium how to display Web pages

Displaying A Web Page in Chrome

Conceptualization of application layering

See Original document: Http://goo.gl/MsEJX

Each box represents a layer of abstraction. The lower layer does not depend on the upper layer.

• WebKit: Rendering engine. Safari,chrome/chromium are in use. The domestic Baidu browser, QQ browser, Cheetah and so on. Port (that is, porting) is part of WebKit, which is responsible for integrating system-related services such as resource downloads, image decoding, and so on.
• Glue: Glue layer. is responsible for converting the WebKit data type to the Chromium data type (consistent with the glue meaning in the Android platform). He belonged to the WebKit embedded layer. It is this layer that allows WebKit to be embedded in the system. It is also the foundation of chromium and Test_shell.
• Renderer/render Host:chromium of multi-process parts. It handles notifications and commands.
• The main class of the Webcontents:content module, a component that can be leveraged. You can use it to achieve multi-process rendering. For more details, click Content module pages.
• Browser: Represents the browser window. It contains multiple webcontent.
• Tab Helpers: A group of independent objects. They can be attached to a webcontents.

Webkit

We use open source WebKit to implement page layouts. This part of the code is pulled from Apple, placed in the Third_party/webkit directory (after enabling the blink is not the same as the pro ... ）。 The WebKit is comprised of two engines: WebCore and JavaScriptCore. WebCore is responsible for page layout; JavaScriptCore is responsible for running JS code. We will run JavaScriptCore only in the case of testing. In normal circumstances, we use our own V8 engine. It has a much better performance than JavaScriptCore. We didn't use the WebKit layer (Apple's salutation).

WebKit port (porting or adaptation layer)

At the bottom, we have our own WebKit adaptation layer (port). Platform-related functional interfaces are implemented in this area. The code is located in the Chromium directory under the WebKit directory. In fact, many of the transplants are OS-independent. But like font rendering, it must be tied to the platform.

• Network traffic is handled by a multi-process resource-loading system, rather than relying on the OS.
• The image uses the Skia graphics library developed for Android. This is a cross-platform graphics library that handles all images and graphics. The Skia code is located in the/third_party/skia directory. The entry for the graphics operation is in/webkit/port/platform/graphics/graphicscontextskia.cpp.

WebKit glue (glue layer)

Chromium apps use data types that are different from WebKit source code, code styles, and code layouts. The WebKit glue provides a more convenient embedding API. The API uses the Google code type, for example, we use std:string instead of webcore::string and replace Kurl with Gurl. The glue code is located in the/webkit/glue directory. Glue objects are named similar to WebKit objects, but all start with "Web". For example, Webcore::frame becomes webframe.

The WebKit glue layer separates the chromium code from the WebCore data type, minimizing the effect of webcore on chromium. Therefore, the data types in WebCore are never used directly by chromium.

The "Test Shell" app is a "bare" web browser for testing WebKit porting and glue code only. It communicates with the WebKit using the glue interface. Chromium is doing the same thing. It provides developers with a simpler way to test new code without needing to focus on the many complex browser feature, threads, and processes. WebKit's automated testing is also run by this application. However, the disadvantage of test shell is that it is not the same as chromium. The content module is embedded in an application called "Content Shell".

Render Process

The chromium render process is embedded WebKit port via the glue interface. It does not have much code: its primary duty is to connect the browser to the other end of the IPC channel-Renderer.

The most important class in Renderer is Renderview, which is located in/content/renderer/render_view_impl.cc. This object represents a Web page. It handles all the navigation related commands. These commands can come from the browser process or to the browser process. The Renderview class inherits from Renderwidget. Renderwidget provides handling of drawing and input events. Renderview communicates with the browser process through global object renderprocess.

What's the difference between Faq:renderwidget and Renderview?

Renderwidget implements the abstract interface webwidgetdelegate of the glue layer, which maps to Webcore::widget. This is the most basic window on the screen. The window receives the input event and the result of the drawing is also sent to the window. Renderview inherits from Renderwidget. It is the content of a tab or a pop-up window. It handles navigational-nature commands (navigation commands??). ）。 Renderwidget can exist only in one case, independent of Renderview: A selection box on a Web page. These boxes usually come with a downward arrow. This arrow is used for pop-up options. This selection frame friend is rendered with the native window. Because only then, the selection box will appear above the other elements. These windows need to receive input events, but do not have a separate "Web page" (that is, renderview) to do this.

Threads in the renderer

Each of the renderer has two threads. One is the render thread (that is, the rendering threads) and the other is the main thread. Code like Renderview and WebKit runs in this thread. When renderer needs to communicate with browser, the message is first sent to the main thread. The main thread is responsible for forwarding the message to the browser process. This mechanism, among other things, allows us to send messages to browser synchronously. This happens in a small number of operations. These actions usually need to wait for the browser's return results to continue. For example, through JS to get a page of cookies. At this point, the renderer thread is blocked. The main thread enqueue all messages received until the correct response is received. Any messages received during this period will be sent to the renderer thread, taking the normal process.

Browser process

Low-level objects (low-level browser process objects)

The IPC communication for all renderer processes is done in the I/O thread of the browser. This thread also handles network traffic. This scenario avoids the impact on user interaction.

When the main thread initializes a Renderprocesshost object, the object creates a new renderer process and assigns a channelproxy to renderer (named pipes). The object runs in the I/O thread of the browser, listens to the named pipe and automatically forwards the message to the Renderprocesshost object (the object is on the UI thread, the mainline thread). A Resourcemessagefilter object is installed on the channel and is used to worry about specific messages. These specific messages can be processed directly by the I/O thread, such as network requests. This filtering behavior occurs in resourcemessagefilter::onmessagereceived. The renderprocesshost of the UI line thread is responsible for distributing all view-related messages to the appropriate renderviewhost. This distribution occurs in renderprocesshost::onmessagereceived.

Advanced Browse Process objects (high-level browser process objects)

The view-related message came to renderviewhost::onmessagereceived. Most of these messages have been disposed of here. The remainder is forwarded to the Renderwidgethost base class. These two classes map to Renderview and renderwidget in renderer, respectively. Each platform will have a view class (renderwidgethostview[aura| gtk| mac| Win]) to integrate with the native view system.

The Webcontents object is located above Renderview/widget. Most messages are consumed by method calls on this object. A webcontents represents the content of a Web page. It is the top-level object of the content module. It is responsible for displaying a Web page in a rectangular view. To see the details, click "Content Module Pages".

The Webcontents object is contained by a called Tabcontentswrapper. This class is located in the Chrome directory, which represents a tab (that is, a tab).

Two illustrative examples set cursor (cursor) life cycle of messages

Not currently

The life cycle of a mouse click message

Not currently