Тройная буферизация Android - ожидаемое поведение?

Объем предоставленной буферизации имеет значение только в том случае, если вы держите буферы полными. Это означает, что рендеринг выполняется быстрее, чем их потребляет дисплей.

Метки не отображаются на ваших изображениях, но я предполагаю, что фиолетовая строка над зеленой строкой vsync — это статус BufferQueue. Вы можете видеть, что он обычно имеет 0 или 1 полный буфер в любое время. В самом левом углу «увеличенного слева» изображения вы можете видеть, что у него есть два буфера, но после этого у него есть только один, и на 3/4 экрана вы видите очень короткую фиолетовую полосу. указывает на то, что он едва отрендерил кадр вовремя.

См. этот пост и этот пост для фона.

Обновление для добавленных вопросов...

Подробности в другом посте едва коснулись поверхности. Мы должны пойти глубже.

Счетчик BufferQueue, отображаемый в systrace, представляет собой количество буферов в очереди, т. е. количество буферов, в которых есть содержимое. Когда SurfaceFlinger захватывает буфер для отображения, он немедленно освобождает буфер, изменяя его состояние на «свободный». Это особенно интересно, когда буфер отображается на оверлее, потому что отображение рендерится непосредственно из буфера (в отличие от компоновки в пустой буфер и его отображения).

Позвольте мне повторить это еще раз: буфер, из которого дисплей активно считывает данные для отображения на экране, помечен как «свободный» в BufferQueue. Буфер имеет связанный забор, который изначально «активен». Пока он активен, никому не разрешено изменять содержимое буфера. Когда дисплей больше не нуждается в буфере, он сигнализирует о заборе.

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

Обратите внимание, что вызовы waitForever() появляются только тогда, когда вы не отстаете (левая и правая стороны трассировки). Я не уверен навскидку, почему это вообще происходит, когда в очереди есть только 1 полный буфер - он должен удалять из очереди самый старый буфер, который уже должен был подать сигнал.

Суть в том, что вы никогда не увидите, чтобы BufferQueue превышала два значения для тройной буферизации.

Не все устройства работают так, как описано выше. Nexus 7 (2012 г.) не использует механизм «явной синхронизации», а устройства до ICS вообще не имеют BufferQueues.

Возвращаясь к вашему пронумерованному снимку экрана, да, между «1» и «2» есть много времени, когда ваше приложение может запускать PerformTraversals(). Трудно сказать наверняка, не зная, что делает ваше приложение, но я предполагаю, что у вас есть Управляемый хореографом цикл анимации, который пробуждается при каждом VSYNC и работает. Он не работает чаще, чем это.

Если вы используете системную трассировку Android Breakout, вы можете увидеть, как это выглядит при быстром рендеринге. как вы можете («заполнение очереди») и полагаться на обратное давление BufferQueue для регулирования скорости игры.

Особенно интересно сравнить N4 с 4.3 и N4 с 4.4. На 4.3 трассировка аналогична вашей: очередь в основном колеблется на 1, с регулярными падениями до 0 и случайными всплесками до 2. На 4.4 очередь почти всегда равна 2 со случайным падением до 1. В обоих случаях это спать в eglSwapBuffers(); в 4.3 трассировка обычно показывает waitForever() ниже этого, а в 4.4 показывает dequeueBuffer(). (Я не знаю причины этого навскидку.)

Обновление 2. Причиной различий между версиями 4.3 и 4.4 является изменение драйвера Nexus 4. Драйвер 4.3 использовал старый вызов dequeueBuffer, который превращается в dequeueBuffer_DEPRECATED() (Surface.cpp, строка 112). Старый интерфейс не воспринимает забор как "выходной" параметр, поэтому вызов должен вызывать сам waitForever(). Более новый интерфейс просто возвращает забор драйверу GL, который ждет, когда это необходимо (что может быть не сразу).

Обновление 3. Более подробное объяснение теперь доступно здесь. а>.