O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Compositor de Hardware HAL

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A 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 de exibição 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 manipular a composição usando um dos seguintes métodos:

  • Renderizar o conteúdo do aplicativo em um buffer de rascunho, renderizar a barra de status sobre ele, a barra de navegação em cima disso e, finalmente, passar o buffer de rascunho para o hardware de exibição.
  • Passando todos os três buffers para o hardware de exibição e instruindo-o 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 realiza 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, é 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 de sobreposição tem pixels transparentes e camadas sobrepostas são mescladas. Nesses casos, o HWC pode solicitar a composição GLES para algumas ou todas as camadas e reter o buffer composto. Se o SurfaceFlinger pedir para compor o mesmo conjunto de buffers, o HWC pode mostrar o buffer de trabalho composto anteriormente. Isso pode melhorar a vida útil da bateria de um dispositivo ocioso.

Os dispositivos Android normalmente suportam 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.