I have a few questions regarding the SurfaceFlinger:
1) I understand that the app writes to the Surface itself and then moves the buffer to the SurfaceFlinger (let's assume I am using a Hardware Canvas or EGL). What is inside the buffer? raw pixels? compiled openGL code? Can the buffer hold pixels on one transaction and another type of data on another?
2) I read somewhere that the SurfaceFlinger writes to the HWC/DisplayController commands using the OpenGL ES 1.0 API. Is that true?
If it is, then how are version 3.0 commands translated into version 1.0 commands, and where?
Thank you
(1) Assuming you're using OpenGL ES, the app queues up commands to the GL driver, which renders output to a buffer. The Surface is a pool / queue of buffers that are shared between a producer and a consumer; in this case, the app is the producer, and SurfaceFlinger the consumer. For GLES rendering to a Surface, the pool will have two or three buffers (i.e. double- or triple-buffering). The buffer is allocated by gralloc, has a header that describes the contents (width, height, pixel format, etc.), and holds raw pixels.
It's not necessary for the raw pixels to exist, as a sufficiently sophisticated system could just replay the GLES commands when needed, but in practice implementations are filling out buffers and passing the handles around.
Because the gralloc header specifies the buffer attributes, it's possible to change the buffer size and pixel format at any time. Some parts of the system don't expect this. For example, if you feed RGB pixels to the Surface input of a MediaCodec, and then switch to YUV, the codec may fail to detect the change. (This can be demonstrated with some hidden options to screenrecord.)
(2) The Hardware Composer has its own API. It has no relation to GLES. In cases where the number of overlay planes is exceeded, some or all of the composition may be done with GLES, but that's handled within SurfaceFlinger.
More details can be found in the graphics architecture doc.