Release virtual display buffer immediately after HWC set
Previously we only queued a virtual display buffer to the sink when
the next frame was about to be displayed. This may delay the "last"
frame of an animation indefinitely. Now we queue the buffer as soon as
HWC set() returns and gives us the release fence.
Bug: 8384764
Change-Id: I3844a188e0f6ef6ff28f3e11477cfa063a924b1a
diff --git a/services/surfaceflinger/DisplayHardware/BufferQueueInterposer.cpp b/services/surfaceflinger/DisplayHardware/BufferQueueInterposer.cpp
index d8ad224..91f9aea 100644
--- a/services/surfaceflinger/DisplayHardware/BufferQueueInterposer.cpp
+++ b/services/surfaceflinger/DisplayHardware/BufferQueueInterposer.cpp
@@ -16,6 +16,7 @@
#undef LOG_TAG
#define LOG_TAG "BQInterposer"
+//#define LOG_NDEBUG 0
#include "BufferQueueInterposer.h"
@@ -42,19 +43,6 @@
mAcquired(false)
{
BQI_LOGV("BufferQueueInterposer sink=%p", sink.get());
-
- // We need one additional dequeued buffer beyond what the source needs.
- // To have more than one (the default), we must call setBufferCount. But
- // we have no way of knowing what the sink has set as the minimum buffer
- // count, so if we just call setBufferCount(3) it may fail (and does, on
- // one device using a video encoder sink). So far on the devices we care
- // about, this is the smallest value that works.
- //
- // TODO: Change IGraphicBufferProducer and implementations to support this.
- // Maybe change it so both the consumer and producer declare how many
- // buffers they need, and the IGBP adds them? Then BQInterposer would just
- // add 1 to the source's buffer count.
- mSink->setBufferCount(6);
}
BufferQueueInterposer::~BufferQueueInterposer() {