O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Hardware Composer HAL

O HAL do Hardware Composer (HWC) determina a maneira mais eficiente de compor buffers com o hardware disponível. Como um HAL, sua implementação é específica do dispositivo e geralmente feita pelo OEM do hardware de exibição.

O valor dessa abordagem é fácil de reconhecer quando você considera os planos de sobreposição , que compõem vários buffers no hardware da tela em vez da GPU. Por exemplo, considere um telefone Android típico na orientação retrato, com a barra de status na parte superior, a barra de navegação na parte inferior e o conteúdo do aplicativo em todos os outros lugares. O conteúdo de cada camada está em buffers separados. Você pode lidar com a composição usando um dos seguintes métodos:

  • Renderizar o conteúdo do aplicativo em um buffer de trabalho e, em seguida, renderizar a barra de status sobre ele, a barra de navegação em cima e, finalmente, passar o buffer de trabalho para o hardware de exibição.
  • Passar todos os três buffers para o hardware de exibição e instruí-lo a ler dados de diferentes buffers para diferentes partes da tela.

A última abordagem pode ser significativamente mais eficiente.

Os recursos do processador de vídeo variam significativamente. O número de sobreposições, se as camadas podem ser giradas ou combinadas, e as restrições de posicionamento e sobreposição podem ser difíceis de expressar por meio de uma API. Para acomodar essas opções, o HWC executa os seguintes cálculos:

  1. O SurfaceFlinger fornece ao HWC uma lista completa de camadas e pergunta: "Como você deseja lidar com isso?"
  2. O HWC responde marcando cada camada como composição de dispositivo ou cliente.
  3. O SurfaceFlinger cuida de qualquer cliente, passando o buffer de saída para o HWC e permite que o HWC cuide do resto.

Como os fornecedores de hardware podem personalizar o código de tomada de decisão sob medida, é possível obter o melhor desempenho de cada dispositivo.

Os planos de sobreposição podem ser menos eficientes do que a composição GL quando nada na tela está mudando. Isso é particularmente verdadeiro quando o conteúdo da sobreposição tem pixels transparentes e camadas sobrepostas são mescladas. Nesses casos, o HWC pode solicitar a composição do GLES para algumas ou todas as camadas e reter o buffer composto. Se SurfaceFlinger solicitar a composição do mesmo conjunto de buffers, o HWC pode mostrar o buffer temporário composto anteriormente. Isso pode melhorar a vida útil da bateria de um dispositivo inativo.

Os dispositivos Android geralmente oferecem suporte a quatro planos de sobreposição. A tentativa de compor mais camadas do que sobreposições faz com que o sistema use a composição GLES para algumas delas, o que significa que o número de camadas usadas por um aplicativo pode ter um impacto mensurável no consumo de energia e no desempenho.