Hardware Composer (HWC) HAL определяет наиболее эффективный способ объединения буферов с доступным оборудованием. Как и HAL, его реализация зависит от устройства и обычно выполняется OEM-производителем оборудования дисплея.
Ценность этого подхода легко осознать, если принять во внимание плоскости наложения , которые объединяют несколько буферов в аппаратном обеспечении дисплея, а не в графическом процессоре. Например, рассмотрим типичный телефон Android в книжной ориентации, со строкой состояния вверху, панелью навигации внизу и содержимым приложений повсюду. Содержимое каждого слоя находится в отдельных буферах. Вы можете обрабатывать композицию, используя любой из следующих методов:
- Рендеринг содержимого приложения в рабочий буфер, затем рендеринг над ним строки состояния, панели навигации поверх нее и, наконец, передача рабочего буфера на аппаратное обеспечение дисплея.
- Передача всех трех буферов аппаратному обеспечению дисплея и указание ему читать данные из разных буферов для разных частей экрана.
Последний подход может быть значительно более эффективным.
Возможности процессора дисплея существенно различаются. Количество наложений, возможность вращения или смешивания слоев, а также ограничения на позиционирование и перекрытие может быть сложно выразить через API. Чтобы учесть эти параметры, HWC выполняет следующие расчеты:
- SurfaceFlinger предоставляет HWC полный список слоев и спрашивает: «Как вы хотите с этим справиться?»
- HWC реагирует, маркируя каждый уровень как состав устройства или клиента.
- SurfaceFlinger заботится о любом клиенте, передавая выходной буфер в HWC и позволяя HWC обрабатывать все остальное.
Поскольку поставщики оборудования могут адаптировать код принятия решений по индивидуальному заказу, можно добиться максимальной производительности от каждого устройства.
Плоскости наложения могут быть менее эффективными, чем композиция GL, когда на экране ничего не меняется. Это особенно актуально, когда содержимое наложения имеет прозрачные пиксели и перекрывающиеся слои смешиваются. В таких случаях HWC может запросить композицию GLES для некоторых или всех слоев и сохранить составной буфер. Если SurfaceFlinger запрашивает объединение одного и того же набора буферов, HWC может показать ранее составленный рабочий буфер. Это может продлить срок службы батареи бездействующего устройства.
Устройства Android обычно поддерживают четыре плоскости наложения. Попытка объединить больше слоев, чем наложений, приводит к тому, что система использует композицию GLES для некоторых из них, а это означает, что количество слоев, используемых приложением, может оказать заметное влияние на энергопотребление и производительность.
,Hardware Composer (HWC) HAL определяет наиболее эффективный способ объединения буферов с доступным оборудованием. Как HAL, его реализация зависит от устройства и обычно выполняется OEM-производителем оборудования дисплея.
Ценность этого подхода легко понять, если принять во внимание плоскости наложения , которые объединяют несколько буферов в аппаратном обеспечении дисплея, а не в графическом процессоре. Например, рассмотрим типичный телефон Android в книжной ориентации, со строкой состояния вверху, панелью навигации внизу и содержимым приложений повсюду. Содержимое каждого слоя находится в отдельных буферах. Вы можете обрабатывать композицию, используя любой из следующих методов:
- Рендеринг содержимого приложения в рабочий буфер, затем рендеринг над ним строки состояния, панели навигации поверх нее и, наконец, передача рабочего буфера на аппаратное обеспечение дисплея.
- Передача всех трех буферов аппаратному обеспечению дисплея и указание ему читать данные из разных буферов для разных частей экрана.
Последний подход может быть значительно более эффективным.
Возможности процессора дисплея существенно различаются. Количество наложений, возможность вращения или смешивания слоев, а также ограничения на позиционирование и перекрытие может быть сложно выразить через API. Чтобы учесть эти параметры, HWC выполняет следующие расчеты:
- SurfaceFlinger предоставляет HWC полный список слоев и спрашивает: «Как вы хотите с этим справиться?»
- HWC реагирует, маркируя каждый уровень как состав устройства или клиента.
- SurfaceFlinger заботится о любом клиенте, передавая выходной буфер в HWC и позволяя HWC обрабатывать все остальное.
Поскольку поставщики оборудования могут адаптировать код принятия решений по индивидуальному заказу, можно добиться максимальной производительности от каждого устройства.
Плоскости наложения могут быть менее эффективными, чем композиция GL, когда на экране ничего не меняется. Это особенно актуально, когда содержимое наложения имеет прозрачные пиксели и перекрывающиеся слои смешиваются. В таких случаях HWC может запросить композицию GLES для некоторых или всех слоев и сохранить составной буфер. Если SurfaceFlinger запрашивает объединение одного и того же набора буферов, HWC может показать ранее составленный рабочий буфер. Это может продлить срок службы батареи бездействующего устройства.
Устройства Android обычно поддерживают четыре плоскости наложения. Попытка объединить больше слоев, чем наложений, приводит к тому, что система использует композицию GLES для некоторых из них, а это означает, что количество слоев, используемых приложением, может оказать заметное влияние на энергопотребление и производительность.
,Hardware Composer (HWC) HAL определяет наиболее эффективный способ объединения буферов с доступным оборудованием. Как и HAL, его реализация зависит от устройства и обычно выполняется OEM-производителем оборудования дисплея.
Ценность этого подхода легко осознать, если принять во внимание плоскости наложения , которые объединяют несколько буферов в аппаратном обеспечении дисплея, а не в графическом процессоре. Например, рассмотрим типичный телефон Android в книжной ориентации, со строкой состояния вверху, панелью навигации внизу и содержимым приложений повсюду. Содержимое каждого слоя находится в отдельных буферах. Вы можете обрабатывать композицию, используя любой из следующих методов:
- Рендеринг содержимого приложения в рабочий буфер, затем рендеринг над ним строки состояния, панели навигации поверх нее и, наконец, передача рабочего буфера на аппаратное обеспечение дисплея.
- Передача всех трех буферов аппаратному обеспечению дисплея и указание ему читать данные из разных буферов для разных частей экрана.
Последний подход может быть значительно более эффективным.
Возможности процессора дисплея существенно различаются. Количество наложений, возможность вращения или смешивания слоев, а также ограничения на позиционирование и перекрытие может быть сложно выразить через API. Чтобы учесть эти параметры, HWC выполняет следующие расчеты:
- SurfaceFlinger предоставляет HWC полный список слоев и спрашивает: «Как вы хотите с этим справиться?»
- HWC реагирует, маркируя каждый уровень как состав устройства или клиента.
- SurfaceFlinger заботится о любом клиенте, передавая выходной буфер в HWC и позволяя HWC обрабатывать все остальное.
Поскольку поставщики оборудования могут адаптировать код принятия решений по индивидуальному заказу, можно добиться максимальной производительности от каждого устройства.
Плоскости наложения могут быть менее эффективными, чем композиция GL, когда на экране ничего не меняется. Это особенно актуально, когда содержимое наложения имеет прозрачные пиксели и перекрывающиеся слои смешиваются. В таких случаях HWC может запросить композицию GLES для некоторых или всех слоев и сохранить составной буфер. Если SurfaceFlinger запрашивает объединение одного и того же набора буферов, HWC может показать ранее составленный рабочий буфер. Это может продлить срок службы батареи бездействующего устройства.
Устройства Android обычно поддерживают четыре плоскости наложения. Попытка объединить больше слоев, чем наложений, приводит к тому, что система использует композицию GLES для некоторых из них, а это означает, что количество слоев, используемых приложением, может оказать заметное влияние на энергопотребление и производительность.