Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Compositor de hardware HAL

Hardware Composer (HWC) HAL determina la forma más eficiente de combinar búferes con el hardware disponible. Como HAL, su implementación es específica del dispositivo y generalmente la realiza el OEM del hardware de 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 en la GPU. Por ejemplo, considere 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 aplicación en cualquier otro lugar. El contenido de cada capa está en búferes separados. Puede manejar la composición utilizando cualquiera de los siguientes métodos:

  • Representar el contenido de la aplicación en un búfer temporal, luego representar la barra de estado sobre él, la barra de navegación encima y, finalmente, pasar el búfer temporal al hardware de la pantalla.
  • Pasar los tres búferes al hardware de visualización e indicarle que lea datos de diferentes búferes para diferentes partes de la pantalla.

El último enfoque puede ser significativamente más eficiente.

Las capacidades del procesador de pantalla varían significativamente. El número de superposiciones, si las capas se pueden rotar o combinar, y las restricciones de posicionamiento y 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:

  1. SurfaceFlinger proporciona a HWC una lista completa de capas y pregunta: "¿Cómo quieres manejar esto?"
  2. HWC responde marcando cada capa como dispositivo o composición de cliente.
  3. SurfaceFlinger se encarga de cualquier cliente, pasa el búfer de salida a HWC y deja que HWC se encargue del resto.

Debido a que los proveedores de hardware pueden personalizar el código de toma de decisiones a medida, es posible obtener el mejor rendimiento de cada dispositivo.

Los planos superpuestos pueden ser menos eficientes que la composición GL cuando no cambia nada en la pantalla. Esto es particularmente cierto cuando los contenidos superpuestos tienen píxeles transparentes y las capas superpuestas están mezcladas. En tales casos, el HWC puede solicitar la composición GLES para algunas o todas las capas y retener el búfer compuesto. Si SurfaceFlinger solicita componer el mismo conjunto de búferes, el HWC puede mostrar el búfer temporal compuesto previamente. Esto puede mejorar la duración de la batería de un dispositivo inactivo.

Los dispositivos Android suelen admitir cuatro planos de superposición. Intentar componer más capas que superposiciones hace que el sistema use la composición GLES para algunas de ellas, lo que significa que la cantidad de capas utilizadas por una aplicación puede tener un impacto medible en el consumo de energía y el rendimiento.