HAL Hardware Composer

L'HAL Hardware Composer (HWC) determina il modo più efficiente per comporre i buffer con l'hardware disponibile. In quanto HAL, la sua implementazione è specifica del dispositivo e in genere viene eseguita dall'OEM dell'hardware del display.

Il valore di questo approccio è facile da riconoscere se si considerano i piani di sovrapposizione, che compongono più buffer nell'hardware di visualizzazione anziché nella GPU. Ad esempio, prendi in considerazione un tipico smartphone Android con orientamento verticale, con la barra di stato in alto, la barra di navigazione in basso e i contenuti dell'app ovunque. I contenuti di ciascun livello si trovano in buffer separati. Puoi gestire la composizione utilizzando uno dei seguenti metodi:

  • Eseguire il rendering dei contenuti dell'app in un buffer scratch, quindi eseguire il rendering della barra di stato sopra, della barra di navigazione sopra e infine passare il buffer scratch all'hardware del display.
  • Passare tutti e tre i buffer all'hardware del display e chiedergli di leggere i dati da buffer diversi per parti diverse dello schermo.

Quest'ultimo approccio può essere notevolmente più efficiente.

Le funzionalità dei processori dei display variano notevolmente. Il numero di overlay, la possibilità di ruotare o fondere i livelli e le limitazioni relative al posizionamento e alla sovrapposizione possono essere difficili da esprimere tramite un'API. Per supportare queste opzioni, il Centro per la salute e il benessere degli animali esegue i seguenti calcoli:

  1. SurfaceFlinger fornisce a HWC un elenco completo dei livelli e chiede: "Come vuoi gestire questa situazione?"
  2. HWC risponde contrassegnando ogni livello come composizione del dispositivo o del client.
  3. SurfaceFlinger si occupa di qualsiasi client, passando il buffer di output a HWC e lasciando che sia HWC a gestire il resto.

Poiché i fornitori di hardware possono personalizzare il codice decisionale, è possibile ottenere il rendimento migliore da ogni dispositivo.

I piani di overlay potrebbero essere meno efficienti della composizione GL quando non cambia nulla sullo schermo. Questo è particolarmente vero quando i contenuti in overlay hanno pixel trasparenti e i livelli sovrapposti vengono fusi. In questi casi, l'HWC può richiedere la composizione GLES per alcuni o tutti i livelli e conservare il buffer composito. Se SurfaceFlinger chiede di comporre lo stesso insieme di buffer, l'HWC può mostrare il buffer scratch composito in precedenza. In questo modo puoi migliorare la durata della batteria di un dispositivo inattivo.

In genere, i dispositivi Android supportano quattro piani di overlay. Il tentativo di comporre più livelli rispetto agli overlay fa sì che il sistema utilizzi la composizione GLES per alcuni di essi, il che significa che il numero di livelli utilizzati da un'app può avere un impatto misurabile sul consumo energetico e sulle prestazioni.