Chromium a brief introduction and learning Plan of the Web entry event handling mechanism

When users browse the Web, they need to interact with the Web page, such as swiping, kneading, and clicking links in the Web page. These interactions are also known as user input events, and the browser needs to respond quickly to them, such as updating the contents of the Web page or opening a new Web page in a timely manner. The ability of a browser to respond quickly to user input events is critical because it is about the user's experience when browsing the Web, especially when users swipe and pinch pages. In this article, we will briefly introduce the chromium of user input events and develop a follow-up learning Plan.

Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo, welcome attention!

On any platform, user input events are captured and distributed by the system and are generally assigned to the currently active application. The application then finds the control corresponding to the location where the input event was generated, based on its own UI structure, and then gives the input event to the control to handle. On the Android platform, the user input event capture and distribution process can refer to the previous Android application keyboard (KEYBOARD) Message processing mechanism analysis article.

The browser acts as an application, and its user input events are also distributed to the system after it is captured. From the previous chromium multi-process architecture brief introduction and Learning plan this series of articles can be known that chromium-based browser is a multi-process architecture, it mainly has browser, render and GPU three of processes. Where the browser process is responsible for creating the UI structure of the browser, render is responsible for loading the Web content, and the GPU process is responsible for rendering the Web content on the browser's UI. These knowledge points can refer to the chromium hardware accelerated rendering mechanism Basics Brief introduction and Learning Plan, Chromium page loading process brief introduction and learning Plan and Chromium Web page rendering mechanism brief introduction and learning Plan of these three series of articles.

Take Chromium's own content Shell apk as an example, and its browser process creates a UI structure of 1:

Figure 1 The UI structure of the Content Shell apk

The browser window created by the browser process is described by a contentshellactivity. This contentshellactivity contains a shellmanager. This shellmanager also contains a shell. Note that both the Shellmanager and the shell are part of a layout element.

A shell consists of a toolbar and a contentview. Where toolbar is used to enter the content of the Web page Url,contentview used to represent the URL. Contentview contains a surfaceview, the content of the Web page is actually rendered on this surfaceview.

When a user interacts with a Web page, the resulting input events are distributed to contentview processing. The overall process of processing 2 is as follows:

Figure 2 User input event handling process

Contentview runs in the browser process, and it receives input events first in the browser process, primarily to check gesture operations, such as whether continuous input events produce sliding and kneading events. The browser process then sends the input event that occurs and its resulting gesture action to the render process through an IPC message of type Inputmsg_handleinputevent.

The inputmsg_handleinputevent message that the browser process sends to the render process is first intercepted by the compositor thread. The compositor thread is primarily to check if the message contains a swipe and pinch gesture operation. If they are included, apply them to the CC Active Layer tree. Other input things will be forwarded to main thread processing. The main thread mainly gives input events to WebKit processing, which means they are applied to the DOM tree maintained by WebKit. For a detailed introduction to the compositor thread and main thread in the render process, refer to the previous Chromium page rendering mechanism for a brief introduction and Learning Plan article.

Next we take the touch event as an example to briefly describe the process of the browser process and the compositor thread of the render process, the main thread handling the input event.

The browser process handles the touch event as shown in procedure 3:

Figure 3 process of browser process handling touch events

When a touch event occurs, the member function ontouchevent of the Contentview class is called by the Android system. Create process analysis from OpenGL context drawing surface from front chromium hardware accelerated rendering the article knows that every Contentview object in the Java layer should have a Contentviewcore object in the C + + layer. When each Contentview object in the Java layer obtains a touch event, the touch event is distributed to the C + + layer and its corresponding Contentviewcore object processing. This is implemented by calling the member function of the Contentviewcore class ontouchevent.

The C + + layer's Contentviewcore objects are passed a touch event from the Java layer, respectively, through a Gesture dector and a scale Gesture Detector checks to see if the touch event produced a swipe (Scroll) and pinch (Pinch) gesture operation. If so, they will be packaged in a gesture packet. This gesture packet is further passed through a Inputrouter object encapsulated in a inputmsg_handleinputevent message sent to the render process.

Note that the original touch event is also encapsulated by the above Inputrouter object in a separate inputmsg_handleinputevent message that is sent to the render process for processing. This means that a touch event, in the case of a gesture operation, sends two inputmsg_handleinputevent messages to the render process by the browser process. One of these describes a gesture operation, and the other describes the original input event.

When the render process starts, it registers a filter of type inputevent, which is used to intercept the input event messages sent by the browser process, as shown in 4:

Figure 4 compositor threading process for slide and pinch gesture manipulation

Filter intercepts the IPC message process, you can refer to the previous Chromium IPC message sending, receiving and distribution mechanism analysis article.

InputEvent filter intercepts the inputmsg_handleinputevent message sent over by the browser process, it is assigned to compositor thread processing. The compositor thread further checks whether this inputmsg_handleinputevent message is a swipe gesture operation or a pinch gesture operation. If so, apply them to the CC Active Layer tree. Otherwise, the intercepted Inputmsg_handleinputevent message is forwarded to the main thread for processing.

From the previous Chromium web page rendering mechanism brief introduction and Learning plan this series of articles can be known that the CC active layer tree is obtained by activating the CC Pending layer tree, and the CC Pending layer tree is synchronized by the CC The Layer tree gets. Theoretically, the compositor thread should apply the swipe and pinch gesture action on the CC Layer tree, then sync to the CC Pending layer tree, and then activate the CC Pending layer tree as a cc active layer T Ree This will ensure the state consistency of the three tree. However, if you do this, the following four actions are involved:

1. Redraw the CC Layer Tree.

2. Synchronize the redrawn cc layer tree to the CC Pending layer tree.

3. Activate the CC Pending layer tree as a cc active layer tree.

4. Render the CC Active Layer tree.

This process is too long to respond quickly to user input. The CC Active Layer tree describes the content of the Web page that the user is currently seeing on the screen, and when the user slides or pinches the page, the content of the page does not change materially, except that the position or zoom factor has changed, which can be achieved through the currently used CC active Layer tree to handle. This saves you from the first three operations, so you can quickly respond to user input. From here we can also see why chromium to use three tree to describe the same page, in fact, in order to be able to respond quickly to user input, improve the user experience of web browsing.

However, if you apply only the swipe and pinch gesture action on the CC Active layer tree, it will cause its state to be inconsistent with the CC Layer tree, which is not allowed. To solve this problem, the Compsitor thread also requests the scheduler to perform a commit operation. This commit action will trigger the main thread to redraw the CC Layer Tree. Before drawing the CC layer tree, the main thread collects the swipe and pinch operations that were previously applied on the CC Active layer tree, and applies them on top of the CC layer tree that is about to be drawn. This guarantees that its status is consistent with the CC active Layer tree. Note that the swipe and pinch gesture actions are applied on the CC Active Layer tree and the cc Layer tree is redrawn separately in the compositor thread and the main thread, which are executed concurrently.

For inputmsg_handleinputevent messages that are not descriptive gesture operations, the compositor thread will be forwarded to main threading, as shown in 5:

Figure 5 The process of the main thread handling touch events

From the previous Chromium Web page frame tree creation Process Analysis article, you can know that the main thread will load the content of the Web page, the WebKit inside the creation of a Webviewimpl object. We can interpret this Webviewimpl object as an interface that WebKit provides externally. With this interface, chromium can manipulate the Web page that webkit it to load, parse, and render.

The main thread receives the Inputmsg_handleinputevent message sent by Compositor and calls the member function handleinputevent of the Webviewimpl object above to notify WebKit of the The inputmsg_handleinputevent message describes the input event to be processed. in our scenario, this input event is a touch event.

        WebKit received the Touch event notification, the first thing to do is to do hit test, which is to detect touch event on which page element it occurred, Then the received touch thing piece is given to the page element for processing. Note that the page element here refers to the node in the DOM tree of the Web page, which is DOM node. Once the target page element is found, WebKit invokes its member function, Dispatchtouchevent, to handle the touch event that is currently occurring.

        Now the most important thing is the DOM Find the target Dom Node in the tree. Each input event is associated with a location, and all DOM node at that location may be the target DOM node. If the input event takes place without DOM node, or if there is only one DOM node, then things are good. But often there are multiple DOM node in this position, so you need to set one of them to be the target DOM node. In general, the DOM node with the highest position on the z axis is the target DOM node to find.

       dom Tree records the Z-index value of each DOM node. Theoretically, with these z-index values, it is possible to determine the target DOM node of an input event, that is, the DOM tree can be used to determine . But from the previous Chromium page graphics Layer tree creation process analysis, a DOM node z-index value It does not ultimately determine its position on the z axis, but also relates to the Z-index value of the stacking context in which the DOM resides. For example, suppose there are two stacking Context,sc1 and SC2. Where the Z-index value of SC1 is equal to 0,sc2 value equals 1. SC1 contains a DOM Node whose z-index value equals 9,SC2 contains a DOM Node, whose z-index value is equal to 6. The final effect is that DOM node with a Z-index value of 6 is above DOM node with a Z-index value of 9. This is because the former stacking context is z-index value for the sake of large.

       webkit maintained render Layer Tree Records all stacking the context information, so WebKit does not use DOM tree to determine the target Dom Node while doing the hit test of the input event, but through

        Above is an overview of the overall process of chromium handling input events, which involves the browser process, as well as the compositor thread and main thread in the render process. browser process is responsible for gesture operation detection, chromium, we will follow the following three scenarios for detailed analysis:

browser process for processing input events;

       2. Compositor threading Process Analysis for input events;

       3. The main thread handles the process analysis of the input event.

Please pay attention! More information can also focus on Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo.

Chromium a brief introduction and learning Plan of the Web entry event handling mechanism