Introduction to Surfaceflinger

1. SurfaceFlinger background knowledge

SurfaceFlinger is an independent Service, which receives all Window’s Surface as input. ZOrder, transparency, size, position and other parameters are calculated, and the position of each Surface in the final composite image is calculated, and then the final display buffer is generated by HWComposer or OpenGL, and then displayed on a specific display device.

The following first introduces related concepts:< br> Surface-In Android, Window and Surface correspond one-to-one. If Window is concerned with hierarchy and layout, which is a class defined from the designer’s perspective, Surface is a class that engineers care about and consider from an implementation perspective. The content of the Window changes, and the Surface needs space to record the content of the Window at each moment. In Android’s SurfaceFlinger implementation, usually a Surface has two Buffers, one for painting and one for display. The two Buffers are exchanged at a fixed frequency to realize the dynamic refresh of the Window.

Layer——Layer is the basic operation unit for SurfaceFlinger to synthesize. Layer is created inside SurfaceFlinger when the application requests to create the Surface, so a Surface corresponds to a Layer, but note that Surface does not necessarily correspond to Window. Some Surfaces in Android are not related to a Window, but are created directly by the program, such as Say SurfaceView, used to display video content with hardware output, etc.
When multiple layers are combined, not the entire layer space will be fully displayed. According to the final display effect of this layer, a layer can be divided into many regions. Android SurfaceFlinger defines the following region types:
TransparantRegion: A completely transparent area, and the area under it will be displayed.
OpaqueRegion: A completely opaque region, whether it is displayed depends on whether it is blocked or transparent.
VisibleRegion: Visible area, including completely opaque, unobstructed area or semi-transparent area
VisibleRegion: It is covered by the Region, or is not covered by the Region, or is not covered by the transparent region.

DirtyRegion: The visible part of the changed area, including the new occluded area and the new exposed area.

As shown in the picture above, each application Surface corresponds to a Layer on the SurfaceFlinger side. Each Layer has two buffer which can use (Android4.1, there are three buffer can be used, here with two buffer for example ), a front-end buffer, one Back-end buffer, front-end buffer for display, back-end buffer is used for drawing, what SurfaceFlinger has to do is to put the backend buffer needs to be displayed after the drawing is completed to synthesize the buffer into framebuffer, and then throw it to Display to display.

2. Surfaceflinger workflow

< div align="left">

When the Surface is drawn, an Invalidate Message to the waiting thread of Surfaceflinger, when waitForEvent receives a message Then it will be handed over to onMessageReceivered for processing, and handleMessageTransaction will be called in sequence during processing. span>, handleMessageInvalidate, handleMessageR efresh interface.

handleMessageTransaction-the main processing before the screen and Changes to the application window. The window state can only be changed in a Transaction. Because the change of the window state may cause the visible area of ​​this window and other windows to change, it is necessary to recalculate the visible area of ​​the window. In this sub-process of processing, Android will use the flag bit to treat all layers To traverse, once the state of which window has changed, set the flag to recalculate the visible area of ​​this window in the future.

handleMessageInvalidate-the main call handlePageFlip() function, this function is mainly from each Layer corresponding to the BufferQueue and update the dirty area according to the content.

handleMessageRefresh-it is merged and rendered output . As the highlight, there are more steps in this step, and the general framework is as follows:

After the merge rendering is complete, the thread continues to wait for the next invalidate message.

Leave a Comment

Your email address will not be published.