L'HAL Hardware Composer (HWC) determina il modo più efficiente per comporre i buffer con l'hardware disponibile. Trattandosi di un HAL, la sua implementazione è specifica per il dispositivo e di solito viene eseguita dall'OEM dell'hardware di visualizzazione.
Il valore di questo approccio è facile da riconoscere quando si considerano i piani di overlay, che compongono più buffer nell' hardware di visualizzazione anziché nella GPU. Ad esempio, considera un tipico smartphone Android in orientamento verticale, con la barra di stato in alto, la barra di navigazione in basso e i contenuti dell'app ovunque. I contenuti di ogni livello si trovano in buffer separati. Puoi gestire la composizione utilizzando uno dei seguenti metodi:
- Rendering dei contenuti dell'app in un buffer temporaneo, quindi rendering della barra di stato sopra, della barra di navigazione sopra e infine passaggio del buffer temporaneo all'hardware di visualizzazione.
- Passaggio di tutti e tre i buffer all'hardware di visualizzazione e istruzione di leggere i dati da buffer diversi per parti diverse dello schermo.
Quest'ultimo approccio può essere notevolmente più efficiente.
Le funzionalità del processore di visualizzazione variano in modo significativo. Il numero di overlay, la possibilità di ruotare o unire i livelli e le restrizioni sul posizionamento e sulla sovrapposizione possono essere difficili da esprimere tramite un'API. Per adattarsi a queste opzioni, l'HWC esegue i seguenti calcoli:
- SurfaceFlinger fornisce all'HWC un elenco completo di livelli e chiede: "Come vuoi gestire questa situazione?"
- L'HWC risponde contrassegnando ogni livello come composizione del dispositivo o del client.
- SurfaceFlinger si occupa di qualsiasi client, passando il buffer di output all'HWC, e lascia che l'HWC gestisca il resto.
Poiché i fornitori di hardware possono personalizzare il codice di presa delle decisioni, è possibile ottenere le migliori prestazioni da ogni dispositivo.
I piani di overlay potrebbero essere meno efficienti della composizione GL quando non cambia nulla sullo schermo. Questo vale in particolare quando i contenuti di overlay hanno pixel trasparenti e i livelli sovrapposti vengono uniti. In questi casi, l'HWC può richiedere la composizione GLES per alcuni o tutti i livelli e conservare il buffer composto. Se SurfaceFlinger chiede di comporre lo stesso set di buffer, l'HWC può mostrare il buffer temporaneo composto in precedenza. In questo modo è possibile migliorare la durata della batteria di un dispositivo inattivo.
In genere, i dispositivi Android supportano quattro piani di overlay. Se si tenta di comporre più livelli di overlay, il sistema utilizza 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.