3

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

EyalBellisha
  • 1,874
  • 19
  • 28

1 Answers1

4

(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.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Thanks, but I am still not sure I understand: I) the commands inside the gralloc buffer are "compiled" openGL commands that can be ran on any device that supports openGL(what kind of "complied" code is it?) II) does the Surface flinger really support only GLES 1.0 commands (when not using overly planes)? and where is the translation from GLES 3.0 to GLES 1.0 done? – EyalBellisha Apr 12 '15 at 18:28
  • The gralloc buffer holds pixel data. The GLES driver has a vendor-specific command queue. *In theory* you could just replay the commands whenever somebody did buffer composition, but in practice the commands run to completion before the fence is signaled and the next stage is able to access the pixels, which it does by reading pixel data out of the gralloc buffer. SurfaceFlinger will use GLES 1.x or 2.x for non-overlay composition; see https://android.googlesource.com/platform/frameworks/native/+/lollipop-release/services/surfaceflinger/RenderEngine/ – fadden Apr 12 '15 at 19:25