La HAL de Hardware Composer (HWC) determina la forma más eficiente de componer búferes con el hardware disponible. Como HAL, su implementación es específica del dispositivo y, por lo general, la realiza el OEM del hardware de la pantalla.
El valor de este enfoque es fácil de reconocer cuando se consideran los planos de superposición, que componen varios búferes en el hardware de la pantalla en lugar de la GPU. Por ejemplo, considera un teléfono Android típico en orientación vertical, con la barra de estado en la parte superior, la barra de navegación en la parte inferior y el contenido de la app en el resto de la pantalla. El contenido de cada capa se encuentra en búferes separados. Puedes controlar la composición con cualquiera de los siguientes métodos:
- Renderizar el contenido de la app en un búfer de trabajo, luego renderizar la barra de estado sobre él, la barra de navegación sobre eso y, finalmente, pasar el búfer de trabajo al hardware de la pantalla
- Pasar los tres búferes al hardware de la pantalla y darle instrucciones para que lea datos de diferentes búferes para diferentes partes de la pantalla
Este último enfoque puede ser mucho más eficiente.
Las capacidades de los procesadores de pantalla varían significativamente. La cantidad de superposiciones, si las capas se pueden rotar o combinar, y las restricciones sobre la posición y la superposición pueden ser difíciles de expresar a través de una API. Para adaptarse a estas opciones, el HWC realiza los siguientes cálculos:
- SurfaceFlinger proporciona a HWC una lista completa de capas y pregunta: "¿Cómo quieres controlar esto?".
- HWC responde marcando cada capa como composición del dispositivo o del cliente.
- SurfaceFlinger se encarga de cualquier cliente, pasa el búfer de salida al HWC y deja que el HWC se encargue del resto.
Dado que los proveedores de hardware pueden personalizar el código de toma de decisiones, es posible obtener el mejor rendimiento de cada dispositivo.
Los planos de superposición pueden ser menos eficientes que la composición de GL cuando no cambia nada en la pantalla. Esto es especialmente cierto cuando el contenido de la superposición tiene píxeles transparentes y las capas superpuestas se combinan. En estos casos, el HWC puede solicitar la composición de GLES para algunas o todas las capas y conservar el búfer compuesto. Si SurfaceFlinger solicita componer el mismo conjunto de búferes, el HWC puede mostrar el búfer de trabajo compuesto anteriormente. Esto puede mejorar la duración de la batería de un dispositivo inactivo.
Por lo general, los dispositivos Android admiten cuatro planos de superposición. Si intentas componer más capas que superposiciones, el sistema usará la composición de GLES para algunas de ellas, lo que significa que la cantidad de capas que usa una app puede tener un impacto medible en el consumo de energía y el rendimiento.