Preliminary Exploration of chromium UI Rendering

Reprinted please indicate the source: http://www.cnblogs.com/fangkm/p/3943896.html

Drawing logic of common UI Libraries

Any mature interface framework has a very complex structure, such as message loop processing, control layout and drawing, focus management, and resource access, the interface framework in chromium is no exception, especially the MVC design method adds complexity to the code structure. We are not going to discuss the chromium interface framework here. This article is only interested in the UI rendering part of chromium. Specifically, it should be the hardware acceleration support for control rendering after the aura architecture is introduced.

In a common directui implementation (Windows Platform), the rendering logic is generally as follows: When a window with an hwnd handle on the outermost layer receives a wm_paint message, the beginpaint function is used to obtain the DC for drawing a window, create a memory DC based on the DC for drawing, and traverse the self-painted controls in the window (in a tree structure ), each control compute needs to update the intersection of the region and its own region, draw the control location corresponding to the Intersection Region on the memory DC, and finally copy the memory DC to the drawing DC by the bitblt series API, to complete a set of rendering logic. People without language skills can describe the process logic in words, which may seem pale and powerless. Please refer to a simple process diagram.

The overall process structure is clear and clear, but it is complicated to implement, especially when processing the control hierarchy, visibility, and calculation of the drawing area. In chromium, the software rendering process of the UI framework is also roughly this process. After hardware rendering is introduced, the compositing layer concept is added to ensure structural consistency, the software rendering process also goes through the CC layer and routes a large circle and is finally drawn on the outputsurface provided by the software rendering. For details, see softwareoutputdevicewin implementation, the software rendering part of chromium will be studied in depth when exploring the CC Library.

Draw logic of chromium UI library after introduction of aura framework

In the general directui library implementation, software rendering is generally used, that is, drawing on DC through a series of GDI functions. Once software rendering encounters a high refresh frequency, for example, video and game images, rendering efficiency is insufficient, and the smoothness of experience is greatly reduced. Therefore, GPU is used for hardware rendering for video or game playback, however, Windows Hardware rendering generally requires window handle hwnd, such as the rendering component vmr filter in DirectShow. However, it is terrible to add a subwindow with hwnd to the directui framework, in this way, the self-painting system is completely damaged, and any fully-Self-painted control cannot be located on top of the hwnd subwindow. The focus logic, message routing, and other systems will be damaged to varying degrees. In a further step, even if a mature directui library is good enough to accommodate the sub-hwnd window logic, imagine if there are multiple UI interfaces that require hwnd, that is also a bad thing. In short, in my opinion, adding a sub-window with hwnd to the directui framework is completely a paradox and a compromise on practical application scenarios. In addition, a major feature of directui is completely self-painted, which makes it easy to develop a colorful interface. Of course, animation logic is indispensable for a cool interface. If animation rendering can be used with GPU, it is also a major boost. So much nonsense. In short, it is necessary to support hardware rendering for the directui library.

It is a great honor that the chromium UI Library supports hardware rendering. Therefore, the aura framework structure is introduced to manage the underlying rendering of the UI. The structure of the rendering logic of the chromium UI framework is roughly as follows:

 

Before introducing the rendering process, it is necessary to understand the aura structure. According to my understanding, the window class in Aura should be the concept of the window in the aura framework. The window also adopts a tree structure, therefore, the role of the windowtreehost class is not difficult to understand. As the host of the window tree, a top-level window is created in windowtreehost as the root node of all window trees. Windowtreehost has different implementations on different platforms. The implementation class in Windows is javastopwindowtreehostwin. It maintains an hwndmessagehandler object to Process Window Creation and Message Processing logics on Windows platforms, hwndmessagehandler is derived from javaswimpl and is responsible for processing a large number of Windows messages and passing the processing logic to javastopwindowtreehostwin through the hwndmessagehandlerdelegate interface. For example, the processing logic of the wm_paint message is delegated to the handlepaint function of worker topwindowtreehostwin in this way.

Before the introduction of aura, the widget class directly connects to hwndmessagehandler. After the introduction of aura, the widget and hwnd are separated, but logically it is still used as the top-level window in the external development interface.

The views framework provides a javastopnativewidgetaura object for the widget as the adaptation to the aura layer. The javastopnativewidgetaura logically maintains only one window object, that is, the content_window _ Member, which corresponds to the entire widget window level, that is to say, the entire widget, including its internal view tree, belongs to a window layer in aura.

In the AURA System, the window and layer are in a one-to-one relationship, which shows that each window is a rendering layer. When the rendering engine needs to collect the rendering logic of each layer before rendering, the layer object delegates the logic to the corresponding window class through the onpaintlayer method of the layerdelegate interface. Similarly, when topnativewidgetaura maintains a window object for the widget, it is obligated to transfer the drawing logic from the window object through the windowdelegate interface, and then throw the logic to the widget object through the nativewidgetdelegate interface, the widget object responds to the onnativewidgetpaint function, traverses its own view tree, and adds tiles to the canvas.

Here, we need to add that the widget's view can also hold the layer object. The structure diagram just now is difficult to mark, and the view also implements the layerdelegate interface, the control can create its own layer Layer as needed and add it to the child node of the layer corresponding to the content_window _ Member of the topnativewidgetaura member. (add the nested layer again, the layer here is the layer of the UI Layer. It is added to its subnodes to the tree level of the CC layer corresponding to the UI Layer, the layer tree of the CC layer is a real rendering tree, and the layer of the UI Layer is a layer adaptation for Aura access. It's a bit difficult. Let's talk about the CC database later ). By calling the setpainttolayer method of view, view creates its own layer. In this case, the view directly implements the onpaintlayer method to process the painting, and the painting level is above the view control where no layer is created. If you want to create a video display control, you can create a layer of your own to draw video data on an independent layer. With so many worships, we still need to configure a sequence diagram. a diagram is worth a thousand words:

 

The logic of the CC database will be studied later. Here, we should consider black box processing. In this process, the rendering driver is driven by the Windows message wm_paint response. This is a typical software rendering process. In addition, you can call the schedulepaint method of the View control to re-paint the control, the redrawing process is to find the layer object bound to the view. If it is not bound, it is always up. The top-level widget can access the layer corresponding to the content_window _ Member of the topnativewidgetaura member through the getlayer method. Find the layer and call the schedulepaint function of the layer to drive the compositor process.

This article will introduce it first. In fact, there are still a lot of logic to explain, such as how to determine whether a single layer or view needs to be re-drawn once the drawing process is triggered. Limited time, limited energy, or leave some passion to study the CC module later.

Preliminary Exploration of chromium UI Rendering