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

BufferQueue e Gralloc

A classe BufferQueue conecta componentes que geram buffers de dados gráficos ( produtores ) a componentes que aceitam os dados para exibição ou processamento posterior ( consumidores ). Quase tudo que move buffers de dados gráficos pelo sistema depende do BufferQueue.

O alocador de memória Gralloc executa alocações de buffer e é implementado por meio de duas interfaces HIDL específicas do fornecedor (consulte hardware/interfaces/graphics/allocator/ e hardware/interfaces/graphics/mapper/ ). A função allocate() leva os argumentos esperados (largura, altura, formato de pixel), bem como um conjunto de sinalizadores de uso.

Produtores e consumidores de BufferQueue

Os consumidores criam e possuem a estrutura de dados BufferQueue e podem existir em processos diferentes dos de seus produtores. Quando um produtor precisa de um buffer, ele solicita um buffer livre de BufferQueue chamando dequeueBuffer() , especificando a largura, altura, formato de pixel e sinalizadores de uso dos buffers. O produtor então preenche o buffer e retorna o buffer para a fila chamando queueBuffer() . Em seguida, o consumidor adquire o buffer com acquireBuffer() e faz uso do conteúdo do buffer. Quando o consumidor releaseBuffer() , ele retorna o buffer para a fila chamando releaseBuffer() . A estrutura de sincronização controla como os buffers se movem no pipeline de gráficos do Android.

Algumas características do BufferQueue, como o número máximo de buffers que ele pode conter, são determinadas em conjunto pelo produtor e pelo consumidor. No entanto, o BufferQueue aloca buffers conforme precisa deles. Os buffers são retidos, a menos que as características mudem; por exemplo, se um produtor solicitar buffers com um tamanho diferente, os buffers antigos serão liberados e os novos serão alocados sob demanda.

O conteúdo do buffer nunca é copiado pelo BufferQueue, pois mover tantos dados é ineficiente. Em vez disso, os buffers são sempre passados ​​por um identificador.

Rastreando BufferQueue com Systrace

Para entender como os buffers gráficos se movem, use o Systrace , uma ferramenta que registra a atividade do dispositivo durante um curto período de tempo. O código gráfico no nível do sistema é bem instrumentado, assim como grande parte do código de estrutura do aplicativo relevante.

Para usar o Systrace, ative as tags gfx , view e sched . Os objetos BufferQueue são exibidos no rastreamento. Por exemplo, se você fizer um rastreamento enquanto o vídeo Play de Grafika (SurfaceView) está em execução, a linha rotulada SurfaceView informa quantos buffers foram enfileirados a qualquer momento.

O valor aumenta enquanto o aplicativo está ativo, o que dispara a renderização de quadros pelo decodificador MediaCodec. O valor diminui enquanto SurfaceFlinger está trabalhando e consumindo buffers. Ao exibir vídeo a 30 fps, o valor da fila varia de 0 a 1 porque a exibição de ~ 60 fps pode acompanhar a fonte. O SurfaceFlinger desperta apenas quando há trabalho a ser feito, não 60 vezes por segundo. O sistema tenta evitar o trabalho e desativa o VSYNC se nada estiver atualizando a tela.

Se você alternar para o vídeo Play de Grafika (TextureView) e obter um novo traço, verá uma linha rotulada com.android.grafika / com.android.grafika.PlayMovieActivity . Esta é a camada de IU principal, que é outro BufferQueue. Como o TextureView é renderizado na camada da IU em vez de em uma camada separada, todas as atualizações orientadas por vídeo são exibidas aqui.

Gralloc

O alocador Gralloc HAL hardware/libhardware/include/hardware/gralloc.h executa alocações de buffer por meio de sinalizadores de uso. Sinalizadores de uso incluem atributos como:

  • Com que frequência a memória será acessada a partir do software (CPU)
  • Com que frequência a memória será acessada do hardware (GPU)
  • Se a memória será usada como uma textura OpenGL ES (GLES)
  • Se a memória será usada por um codificador de vídeo

Por exemplo, se o formato do buffer de um produtor especifica RGBA_8888 pixels e o produtor indica que o buffer será acessado do software (o que significa que um aplicativo tocará pixels na CPU), Gralloc criará um buffer com 4 bytes por pixel na ordem RGBA. Se, em vez disso, um produtor especificar que seu buffer será acessado apenas do hardware e como uma textura GLES, Gralloc pode fazer qualquer coisa que o driver GLES desejar, como ordenação BGRA, layouts não lineares swizzled e formatos de cores alternativos. Permitir que o hardware use seu formato preferido pode melhorar o desempenho.

Alguns valores não podem ser combinados em certas plataformas. Por exemplo, o sinalizador do codificador de vídeo pode exigir pixels YUV, portanto, adicionar acesso ao software e especificar RGBA_8888 falhará.

O identificador retornado por Gralloc pode ser passado entre processos por meio do Binder.

Buffers protegidos

O sinalizador de uso GRALLOC_USAGE_PROTECTED permite que o buffer de gráficos seja exibido apenas por meio de um caminho protegido por hardware. Esses planos de sobreposição são a única forma de exibir conteúdo DRM (buffers protegidos por DRM não podem ser acessados ​​pelo SurfaceFlinger ou pelo driver OpenGL ES).

O vídeo protegido por DRM pode ser apresentado apenas em um plano de sobreposição. Os reprodutores de vídeo que suportam conteúdo protegido devem ser implementados com SurfaceView. O software executado em hardware desprotegido não pode ler ou gravar no buffer; os caminhos protegidos por hardware devem aparecer na sobreposição do Hardware Composer (ou seja, os vídeos protegidos desaparecem da exibição se o Hardware Composer alternar para composição OpenGL ES).

Para obter detalhes sobre conteúdo protegido, consulte DRM .