This document describes how web pages are displayed in Chromium from the bottom up. Be sure you have read themulti-process architecture design document. You will especially want to understand the block diagram of major components. You may also be interested inmulti-process resource loading for how pages are fetched from the network. Conceptual application layers
Each box represents a conceptual application layer. It should generally be possible to build a different browser by picking any layer and replacing the layers above it. Therefore, no layer should have knowledge of or dependencies on any higher-level layers.
WebKitWe use the WebKit open-source project to lay out web pages. This code is pulled from Apple and stored in the /third_party/WebKit directory. WebKit consists primarily of "WebCore" which represents the core layout functionality, and "JavaScriptCore" which runs JavaScript. We only run JavaScriptCore for testing purposes, normally we replace it with our high performance V8 JavaScript engine. We do not actually use the layer that Apple calls "WebKit," which is the embedding API between WebCore and OS X applications such as Safari. We normally refer to the code from Apple generically as "WebKit" for convenience.The WebKit portAt the lowest level we have our WebKit "port." This is our implementation of required platform-specific functionality that interfaces with the platform-independent WebCore code. These files are located in the WebKit tree, typically inchromium directories or as Chromium-suffixed files. Much of our port is not actually OS-specific: you could think of it as the "Chromium port" of WebCore. Some parts, like font rendering, must be handled differently for each platform.
The WebKit glueThe Chromium application uses different types, coding styles, and code layout than the third-party WebKit code. The WebKit "glue" provides a more convenient embedding API for WebKit using Google coding conventions and types (for example, we use std::string instead of WebCore::String and GURL instead of KURL). The glue code is located in /webkit/glue. The glue objects are typically named similar to the WebKit objects, but with "Web" at the beginning. For example, WebCore::Frame becomes WebFrame.The WebKit "glue" layer insulates the rest of the Chromium code base from WebCore data types to help minimize the impact of WebCore changes on the Chromium code base. As such, WebCore data types are never used directly by Chromium. APIs are added to the WebKit "glue" for the benefit of Chromium when it needs to poke at some WebCore object. The "test shell" application is a bare-bones web browser for testing our WebKit port and glue code. It uses the same glue interface for communicating with WebKit as Chromium does. It provides a simpler way for developers to test new code without having many complicated browser features, threads, and processes. This application is also used to run the automated WebKit tests. The render process
TODO(someone who has Illustrator): the above diagram is slightly out of date. The Render thread is now the main thread and the I/O thread is a secondary thread.
Chromium's render process embeds our WebKit port using the glue interface. It does not contain very much code: its job is primarily to be the renderer side of theIPC channel to the browser.. The most important class in the renderer is the RenderView, located in /chrome/renderer/render_view.cc. This object represents a web page. It handles all navigation-related commands to and from the browser process. It derives fromRenderWidget which provides painting and input event handling. TheRenderView communicates with the browser process via the global (per render process)RenderProcess object.
FAQ:
What's the difference between RenderWidget and RenderView?
RenderWidget maps to one
WebCore::Widget object by implementing the abstract interface in the glue layer called
WebWidgetDelegate.. This is basically a Window on the screen that receives input events and that we paint into. A
RenderView inherits from
RenderWidget and is the contents of a tab or popup Window. It handles navigational commands in addition to the painting and input events of the widget. There is only one case where a
RenderWidget exists without a
RenderView, and that's for select boxes on the web page. These are the boxes with the down arrows that pop up a list of options. The select boxes must be rendered using a native window so that they can appear above everything else, and pop out of the frame if necessary. These windows need to paint and receive input, but there isn't a separate "web page" (
RenderView) for them.
Threads in the rendererEach renderer has two threads (see the multi-process architecture page for a diagram, or threading in Chromium for how to program with them). The render thread is where the main objects such as the RenderView and all WebKit code run. When it communicates to the browser, messages are first sent to the main thread, which in turn dispatches the message to the browser process. Among other things, this allows us to send messages synchronously from the renderer to the browser. This happens for a small set of operations where a result from the browser is required to continue. An example is getting the cookies for a page when requested by JavaScript. The renderer thread will block, and the main thread will queue all messages that are received until the correct response is found. Any messages received in the meantime are subsequently posted to the renderer thread for normal processing.The browser processLow-level browser process objectsAll IPC communication with the render processes is done on the I/O thread of the browser. This thread also handles allnetwork communication which keeps it from interfering with the user interface. When a RenderProcessHost is initialized on the main thread (where the user interface runs), it creates the new renderer process and aChannelProxy IPC object with a named pipe to the renderer. This object runs on the I/O thread of the browser, listening to the named pipe to the renderer, and automatically forwards all messages back to theRenderProcess on the UI thread. AResourceMessageFilter will be installed in this channel which will filter out certain messages that can be handled directly on the I/O thread such as network requests. This filtering happens inResourceMessageFilter::OnMessageReceived. The RenderProcessHost on the UI thread is responsible for dispatching all view-specific messages to the appropriateRenderViewHost (it handles a limited number of non-view-specific messages itself). This dispatching happens inRenderProcessHost::OnMessageReceived. High-level browser process objectsView-specific messages come into RenderViewHost::OnMessageReceived. Most of the messages are handled here, and the rest get forwarded to theRenderWidgetHost base class. These two objects map to theRenderView and the RenderWidget in the renderer (see "The Render Process" above for what these mean). On Microsoft Windows, we have aRenderWidgetHostHWND associated with eachRenderWidgetHost that specifically manages events and drawing into a native HWND. Other systems will have a similar class for native input and painting. Above the RenderView/Widget is theWebContents object, and most of the messages actually end up as function calls on that object. AWebContents represents the contents of a tab that shows web data. It derives from the genericTabContents class (there are a number of other specializations ofTabContents for history and downloads, for example). It is the central switching point for most navigation and toplevel browser UI updating.
FAQ: Why are WebContents and RenderViewHost separate? These two objects provide different layers of functionality. You could think of
RenderViewHost as Chromium's "multi-process embedding layer."
RenderViewHost objects could be (but are not currently) used in other parts of the application to render content. For example, you could imagine a dialog box with a web view in it. This could use
RenderViewHost to manage drawing and communication with the render process, but it would not have a "tab" or the normal navigation commands. The
RenderViewHost forwards many messages to the
WebContents via its
RenderViewHostDelegate abstract interface. The
WebContents handles the navigational state and anything related to the UI of the web browser. Our hypothetical dialog box wouldn't need any of this functionality and would only implement the parts of the
RenderViewHostDelegate interface that it cares about.
Illustrative examplesAdditional examples covering navigation and startup are in Getting Around the Chromium Source Code.Life of a "set cursor" messageSetting the cursor is an example of a typical message that is sent from the renderer to the browser. In the renderer, here is what happens.
Then the browser takes control:
Life of a "mouse click" messageSending a mouse click is a typical example of a message going from the browser to the renderer.
Note that many other types of messages are created in the WebContents, especially navigational ones. These follow a similar path from theWebContents to the RenderViewHost. Then the renderer takes control:
|
How Chromium Displays Web Pages
最新推荐文章于 2022-07-08 10:00:00 发布