Hardware Composer（HWC）HAL は、使用可能なハードウェアでバッファを合成する最も効率的な方法を特定します。HAL の実装はデバイス固有で、通常はディスプレイ ハードウェアの OEM が行います。
この方法のメリットは、GPU ではなくディスプレイ ハードウェアで複数のバッファを合成するオーバーレイ プレーンを思い浮かべるとわかりやすいでしょう。たとえば、上部にステータスバー、下部にナビゲーション バー、それ以外の場所にアプリのコンテンツが表示される、縦向きの一般的な Android スマートフォンについて考えてみましょう。各レイヤのコンテンツは別々のバッファにあります。次のいずれかの方法で合成を処理できます。
- アプリのコンテンツをスクラッチ バッファにレンダリングし、その上にステータスバー、さらにその上にナビゲーション バーをレンダリングして、最後にスクラッチ バッファをディスプレイ ハードウェアに渡します。
- 3 つのバッファをすべてディスプレイ ハードウェアに渡し、画面の部分ごとに異なるバッファからデータを読み取るように指示します。
後者の方がはるかに効率的です。
ディスプレイ プロセッサの機能には大きな差があります。オーバーレイの数、レイヤの回転またはブレンドの可否、配置とオーバーラップの制限を API で表現するのは困難です。これらのオプションに対応するため、HWC は次の計算を行います。
- SurfaceFlinger は HWC にレイヤの完全なリストを提供し、処理方法を確認します。
- HWC は、各レイヤにデバイス合成またはクライアント合成のマークを付けて応答します。
- SurfaceFlinger はクライアントをすべて処理して出力バッファを HWC に渡し、HWC が残りを処理できるようにします。
ハードウェア ベンダーは意思決定コードを要求に応じてカスタマイズできるため、すべてのデバイスから最大限のパフォーマンスを引き出すことができます。
画面上に変化がない場合、オーバーレイ プレーンは GL 合成よりも効率が下がる可能性があります。これは特に、オーバーレイ コンテンツに透明ピクセルがあり、オーバーラップ レイヤがブレンドされている場合に当てはまります。この場合、HWC は一部またはすべてのレイヤの GLES 合成をリクエストして合成バッファを保持できます。SurfaceFlinger から同じバッファセットの合成を要求された場合、HWC は以前合成したスクラッチ バッファを表示できます。これにより、アイドル状態のデバイスのバッテリー駆動時間を延ばせます。
Android デバイスは通常、4 つのオーバーレイ プレーンをサポートします。オーバーレイよりも多くのレイヤを合成しようとすると、一部のレイヤに GLES 合成が使用されます。つまり、アプリで使用するレイヤの数が消費電力とパフォーマンスに大きく影響する可能性があります。