Link: blog.csdn.net/u011578734/…

Display List

Android needs to convert the XML layout file into an object that the GPU can recognize and draw. This is done with the help of DisplayList. DisplayList holds all the data information that will be given to the GPU to draw onto the screen.

What is Display List?

Display List is a Buffer that caches drawing commands. The essence of Display List is a Buffer that records the sequence of drawing commands to be executed.

Display List is the basic drawing element of the view. It contains the primitive attributes of the element (position, size, Angle, transparency, etc.) corresponding to the drawXxx() method of the Canvas.

View information transfer process: Canvas(Java API) – > OpenGL(C/C++ Lib) – > Driver – > GPU

In a hardware-accelerated rendering environment, UI rendering of an Android application window takes place in two steps:

  • The first step is to build the Display List, which occurs in the Main Thread of the application process.

  • The second step is to Render the Display List, which occurs in the Render Thread of the application process. The Render Thread Thread is also added to prevent the UI Thread from being overloaded to improve rendering performance.

    These draw commands are eventually converted into Open GL commands to be executed by the GPU. This means that when we call the Canvas API to draw the UI, we actually just record the Canvas API call and its parameters in the Display List, and then wait until the next VSYNC signal arrives, Draw commands recorded in the Display List will be converted to Open GL commands and executed by the GPU.

Construction of Display List

The Display List is built on a view basis, so there should be a Display List for each view.

Android application window views are tree-structured, so their Display List is built from the root view, and the Display List of the child view is included in the Display List of the parent view. This means that the Display List of the root view contains all the drawing commands of the Android application window UI, so we only need to render the Display List of the root view * to get the Android application window UI. **

The Root view of the Android application window is virtual, abstracted as a Root Render Node. In addition, a view with a Background is abstracted as a Background Render Node. Root Render Node, Background Render Node, and other real subviews have Display lists, in addition to TextureView and software-rendered subviews. And it’s built with an object called the Display List Renderer. Finally, the Root Render Node’s Display List is rendered by an object called the Open GL Renderer to get the UI of the Android application window.

TextureView does not have Display lists. They are drawn as Open GL textures using an object called the Layer Renderer, but this texture is not directly rendered. Instead, it records it in the Display List of the superview and renders it later. Similarly, software-rendered child views do not have Display lists. They are drawn on a Bitmap, which is then recorded in the Display List of the parent view before rendering.

The use and advantages of Display List

When a View needs to be rendered for the first time, the Display List will be created. When the View needs to be displayed on the screen, we will execute the GPU’s drawing instruction to render. If the View’s properties change (such as moving position), we simply need to Execute the Display List.

However, if we change the content of some visible component in the View, the previous DisplayList is no longer usable, and we need to create a new DisplayList and re-execute the render instructions to update it to the screen.

Note: Any time the drawing content in the View changes, you need to recreate the DisplayList, render the DisplayList, update it to the screen, and so on. The performance of this process depends on the complexity of your View, the state changes of the View, and the performance of the render pipeline. For example, if a Button size needs to be doubled, the parent View needs to recalculate and position the other child views before increasing the size of the Button. Resizing a View triggers a recalculation of the entire View tree. Changing the position of the View triggers the View tree to recalculate the positions of other views. If the layout is complex, this can easily lead to serious performance problems.

Here’s a summary of the advantages of using DisplayList:

  • The first benefit is that when drawing the next frame of the window, if the UI of a view does not change, it does not need to execute the Canvas API associated with it, that is, it does not need to execute its member function onDraw, but can directly reuse the Display List built last time.

  • The second advantage is that when drawing the next frame of the window, if the UI of a view changes but only some simple attributes, such as position and transparency, are changed, it is not necessary to rebuild its Display List, but directly modify the related attributes of the Display List constructed last time. This also eliminates the need to execute its member function onDraw.

    Under hardware-accelerated conditions, CPU is used to control complex drawing logic, build or update DisplayList. GPU is used to perform graphics calculation and render DisplayList. Under hardware acceleration conditions, the CPU only rebuilds or updates the necessary DisplayList when refreshing the interface, especially when playing animations, to further improve rendering efficiency. To achieve the same effect, try to use simpler DisplayList to achieve better performance (e.g. Shape instead of Bitmap, etc.).

conclusion

  1. Android needs to convert the XML layout file into an object that the GPU can recognize and draw. This is done with the help of DisplayList. DisplayList holds all the data information that will be given to the GPU to draw onto the screen.

  2. Display List is a Buffer that caches drawing commands. The essence of Display List is a Buffer that records the sequence of drawing commands to be executed.

  3. Display List is the basic drawing element of the view. It contains the primitive attributes of the element (position, size, Angle, transparency, etc.) corresponding to the drawXxx() method of the Canvas.

  4. Render Display List, which occurs in the Render Thread of the application process. The Render Thread Thread is also added to prevent the UI Thread from being overloaded to improve rendering performance.

  5. The Display List is built on a view basis, so there should be a Display List for each view.

  6. When a View needs to be rendered for the first time, the Display List will be created. When the View needs to be displayed on the screen, we will execute the GPU’s drawing instruction to render.

  7. When drawing the next frame of the window, if the UI of a view does not change, it does not need to execute its related Canvas API, that is, it does not need to execute its member function onDraw, but directly reuse the Display List built last time.

  8. When drawing the next frame of the window, if the UI of a view changes but only some simple attributes, such as position and transparency, are changed, it is not necessary to rebuild its Display List, but to directly modify the related attributes of the Display List constructed last time. This also eliminates the need to execute its member function onDraw.

  9. Under hardware-accelerated conditions, CPU is used to control complex drawing logic, build or update DisplayList. GPU is used to perform graphics calculation and render DisplayList.