Chromimum Android Rendering Introduction

Conceptually, when using hardware acceleration (AC), the page display is structured as a tile (s), Layer (s), viewport, and so-called textures are what is displayed on the Tile. The biggest benefit of chunking is that the redrawn unit is smaller, which is more advantageous to reduce the system overhead.
(Tile tiles are not as good as tiles ^_^!)

For details, refer to the Web page drawing process when hardware acceleration is turned on.
From the WebKit core to the Chromium cc module, the corresponding relationship is as follows:

Chormium provides multi-threaded rendering (Design Document) through the impl-side painting. The purpose is to isolate the page content of the WebKit kernel from the actual display, and then divide the painting operations into recording and Rasterization.
One of the important concepts is main thread (side) and Impl thread (side).

The Main thread runs on the render thread, including Renderwidget,layertreehost, and so on. The Impl thread runs on compositor threads, including Layertreehostimpl, and so on. The two threads communicate through a proxy. The basic rendering path is like a dot drawing, recording a script before generating an image. It uses the object is skpicture, it can do similar to the Display list function, can record, and then play. This is also the basis for cross-process rendering (it is necessary to encode and decode the process.) ）。
The steps are as follows:
* In main thread, chromium/webkit rendering to a graphical back end (skpicture) is stored by Layertreehost to manage the entire layer Tree. This process is called a record and is not really drawn.
* Submit this data to Layertreehostimpl in Impl thread, the process is upload, and there is a commit.
* Layertreehostimpl again through the awcontents, using the Android GL function for composition, this process is called rastering (rasterization, in fact, is the concept of bitmap display, corresponding to the vector mode of drawing.)

Structurally, layertreehost and Layertreehostimpl form the interface between the main thread and the Impl thread.

At initialization, the process starts with the creation of the Renderviewimpl, as shown (Threadproxy is the implementation of the proxy):

In order to better arrange the task queue for main thread and Impl thread, there will be a scheduler responsible for the task scheduling. The following are the relationships of the classes, and you can see their lifecycle management:

Main Thread (Side)

Layertreehost/layertreehostimpl is just the class of organization and transaction processing, which is actually drawn on the basis of outputsurface and can be understood as a graphical back end. Both Android WebView and CC are based on the operation of the outputsurface to complete the subsequent compositing. Chromium WebView uses the synchronous synthesizer, the Synchronouscompositor, to draw on the UI thread using the system's GL capabilities. There is a string of classes named after Synchronouscompositor.

First, when the Layertreehostimpl is ready, the layertreehost is asked to Outputsurface, Eventually, a outputsurface was created by Renderwidget through Synchronouscompositorfactory and handed over to Layertreehostimpl Management (SCOPED_PTR).

Impl Thread (Side)

In Impl side, awcontents the synth management operations are performed by Browserviewrenderer, It will provide services primarily to Layertreehostimpl and outputsurface through Synchronouscompositorimpl.
The Android WebView is designed in a webcontents that corresponds to a synthesizer, So synchronouscompositoroutputsurface through the routingid can confirm the corresponding Synchronouscompositorimpl.
On Android, the Impl thread is actually running on the UI thread, that is, child compositor on the UI thread. Detailed instructions refer to Urbercomp in Android WebView with detailed instructions.

The following are the main classes of relationships:

Reference: Android 4.4 Browser rendering mechanism parsing.

Attach the Outputsurface initialization and binding process as follows:

In order to support the DRAWGL function (described below), a outputsurface is also created when the drawing is started. Destructors are then refactored in turn, and the flow is as follows:

TileSet & Layer

The Tileset and layer,chromium corresponding to the above are implemented by Picturelayerimpl. The following is the class diagram, no in-depth study, for reference only:
More systematic introduction Look here Chromium Graphics: Again talk about the evolution of chromium WebView hardware rendering mode.

Reference

1. Web page rendering and compositing Acceleration (ii)
2. Chromium Graphics: Further discussion on the evolution of Chromium WebView hardware rendering mode
3. Web page drawing process when hardware acceleration is turned on
4. Impl-side Painting
5. Android Graphics Architecture

Chromimum Android Rendering Introduction