UNDERSTANDING ANDROID GRAPHICS INTERNALS – SURFACEFLINGER (I)

from: https://charleszblog.wordpress.com/2014/02/22/understanding-android-internals-surfaceflinger-i/

Let’s recapture what we have known of SurfaceFlinger from previous posts on Android Graphics.
1. it is a native service implementing BnSurfaceComposer;
2. SurfaceFlinger administrates Surface and Graphic Buffer creation for all graphic clients;
3. Periodically, SurfaceFlinger composes surface layers to the back frame buffer in the frame buffer to the abstraction frame buffer device, and submit layers marked for hardware composition to hwcomposer hardware abstraction module for rendering in case of
4. SurfaceFlinger enforces vsync and triple buffering;
5. Supports snapshot of screen display;
6. Supports HDMI display and virtual display (e.g. Wireless Display);
7. It heavily relies on GLES and EGL.
With these knowledge in mind, we proceed to make some conjectures on it design.
1. To run surface composition, it has to own a dedicated thread;
2. It must maintain a context for each individual surface layer
This is done with Layer structure which tracks orientation, cropping, geometric parameters, color scheme, visible region, etc.
3. It must distinguish between the drawing state (front) and currently rendering state (back) for each layer
This is done with the Layer::State structure.
4. It must quarantine the set of currently active rendering layers from layers newly removed and added
This is done with SurfaceFlinger::state structure
5. vsync event is asynchronous of surface composition, we may need a thread somewhere to monitor vsync event

In next post, we will discuss vsync. In my view, vsync was the main force to drive the redesign of SurfaceFlinger in Jelly Bean.