Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

BufferQueue и Gralloc

Класс BufferQueue связывает компоненты, которые генерируют буферы графических данных ( производители ), с компонентами, которые принимают данные для отображения или дальнейшей обработки ( потребители ). Почти все, что перемещает буферы графических данных через систему, полагается на BufferQueue.

Распределитель памяти Gralloc выполняет распределение буфера и реализуется через два специфичных для поставщика интерфейса HIDL (см. hardware/interfaces/graphics/allocator/ и hardware/interfaces/graphics/mapper/ ). Функция allocate() принимает ожидаемые аргументы (ширина, высота, формат пикселя), а также набор флагов использования.

BufferQueue производителей и потребителей

Потребители создают и владеют структурой данных BufferQueue и могут существовать в разных процессах, чем их производители. Когда производителю нужен буфер, он запрашивает свободный буфер у BufferQueue, вызывая dequeueBuffer() , указывая ширину буферов, высоту, формат пикселя и флаги использования. Затем производитель заполняет буфер и возвращает буфер в очередь, вызывая queueBuffer() . Затем потребитель получает буфер с помощью acquireBuffer() и использует содержимое буфера. Когда потребитель закончил, он возвращает буфер в очередь, вызывая releaseBuffer() . Среда синхронизации управляет тем, как буферы перемещаются по графическому конвейеру Android.

Некоторые характеристики BufferQueue, такие как максимальное количество буферов, которые он может содержать, определяются совместно производителем и потребителем. Тем не менее, BufferQueue распределяет буферы по мере необходимости. Буферы сохраняются, если характеристики не изменяются; например, если производитель запрашивает буферы с другим размером, старые буферы освобождаются и новые буферы выделяются по требованию.

BufferQueue никогда не копирует содержимое буфера, так как перемещение такого большого количества данных неэффективно. Вместо этого буферы всегда передаются дескриптором.

Отслеживание BufferQueue с Systrace

Чтобы понять, как перемещаются графические буферы, используйте Systrace , инструмент, который записывает активность устройства в течение короткого периода времени. Графический код системного уровня хорошо снабжен инструментами, как и большая часть кода соответствующего приложения.

Для того, чтобы использовать Systrace, включите gfx , view и sched теги. Объекты BufferQueue отображаются в трассировке. Например, если вы берете трассировку во время воспроизведения видео Grafika (SurfaceView) , строка с надписью SurfaceView сообщает, сколько буферов было поставлено в очередь в любой момент времени.

Значение увеличивается, когда приложение активно, что запускает рендеринг кадров декодером MediaCodec. Значение уменьшается, пока SurfaceFlinger работает и использует буферы. При отображении видео со скоростью 30 к / с значение очереди изменяется от 0 до 1, поскольку отображение ~ 60 к / с может не отставать от источника. SurfaceFlinger просыпается только тогда, когда нужно выполнить работу, а не 60 раз в секунду. Система пытается избежать работы и отключает VSYNC, если ничего не обновляет экран.

Если вы переключитесь в режим воспроизведения видео Grafika (TextureView) и захватите новую трассировку, вы увидите строку, помеченную com.android.grafika / com.android.grafika.PlayMovieActivity . Это основной уровень пользовательского интерфейса, который является еще одним BufferQueue. Поскольку TextureView отображается в слое пользовательского интерфейса, а не в отдельном слое, здесь отображаются все обновления, управляемые видео.

Gralloc

HAL hardware/libhardware/include/hardware/gralloc.h выполняет распределение буферов с помощью флагов использования. Флаги использования включают такие атрибуты, как:

  • Как часто к памяти будет обращаться из программного обеспечения (ЦП)
  • Как часто к памяти будет обращаться с аппаратного обеспечения (GPU)
  • Будет ли память использоваться в качестве текстуры OpenGL ES (GLES)
  • Будет ли память использоваться видео кодером

Например, если формат буфера производителя указывает RGBA_8888 пикселей, а производитель указывает, что к буферу будет обращаться из программного обеспечения (то есть приложение будет касаться пикселей на ЦП), Gralloc создает буфер с 4 байтами на пиксель в порядке RGBA. Если вместо этого производитель указывает, что его буфер будет доступен только с аппаратного обеспечения, а в качестве текстуры GLES Gralloc может делать все, что хочет драйвер GLES, например упорядочение BGRA, нелинейные макеты и альтернативные форматы цветов. Разрешение аппаратному обеспечению использовать предпочтительный формат может повысить производительность.

Некоторые значения не могут быть объединены на определенных платформах. Например, для флага видеокодера могут потребоваться пиксели YUV, поэтому добавить программный доступ и указать RGBA_8888 не удается.

Дескриптор, возвращаемый Gralloc, может передаваться между процессами через Binder.

Защищенные буферы

Флаг использования GRALLOC_USAGE_PROTECTED позволяет отображать графический буфер только через защищенный аппаратный путь. Эти оверлейные плоскости являются единственным способом отображения содержимого DRM (доступ к защищенным DRM буферам не доступен для SurfaceFlinger или драйвера OpenGL ES).

DRM-защищенное видео может быть представлено только в оверлейной плоскости. Видеоплееры, поддерживающие защищенный контент, должны быть реализованы с SurfaceView. Программное обеспечение, работающее на незащищенном оборудовании, не может читать или записывать буфер; пути с аппаратной защитой должны отображаться в оверлее Hardware Composer (то есть защищенные видео исчезают с дисплея, если Hardware Composer переключается на композицию OpenGL ES).

Для получения подробной информации о защищенном контенте см. DRM .