summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
author Robert Carr <racarr@google.com> 2021-11-30 14:47:02 -0800
committer Rob Carr <racarr@google.com> 2021-12-01 00:07:21 +0000
commitcf2f21fd82d1f95b20077fd9a10aeaa6eb4c202e (patch)
tree9ab788fa5c05e4e51cfa92be67c43df70d0284a8
parentc88ed81a625a2d30fd759af0df4e5c56944f7138 (diff)
BLASTBufferQueue: Cap shadow queue size during sync
While waiting for the transaction commit callback on a previous sync transaction BLASTBufferQueue will halt buffer processing to ensure later frames do not arrive at SurfaceFlinger first. These buffers wait in the shadow queue (tracked by mNumFrameAvailable) to be acquired later. If we end up in a situation where all the buffers are either in a sync transaction or in the shadow queue then dequeue buffer will begin to block. This isn't ideal, as dequeue buffer blocking can cause UI thread to block, aka UI thread can block on RenderThread. However completing the sync transaction (from a previous frame) can also depend on UI thread, aka RenderThread can now block on UI thread (since we need the transaction to apply in order to thaw the shadow queue). In this CL we try and avoid that situation by only keeping 1 frame in the shadow queue while waiting for the sync to complete. If a second frame comes in we will acquire and release the first before acquiring the second. Bug: 200285149 Change-Id: I5072765e7b94820b3e66c557f5a96172ccef8172
-rw-r--r--libs/gui/BLASTBufferQueue.cpp3
1 files changed, 3 insertions, 0 deletions
diff --git a/libs/gui/BLASTBufferQueue.cpp b/libs/gui/BLASTBufferQueue.cpp
index f05426f7cf..dd50ca7fff 100644
--- a/libs/gui/BLASTBufferQueue.cpp
+++ b/libs/gui/BLASTBufferQueue.cpp
@@ -649,6 +649,9 @@ void BLASTBufferQueue::onFrameAvailable(const BufferItem& item) {
// add to shadow queue
mNumFrameAvailable++;
+ if (mWaitForTransactionCallback && mNumFrameAvailable == 2) {
+ acquireAndReleaseBuffer();
+ }
ATRACE_INT(mQueuedBufferTrace.c_str(),
mNumFrameAvailable + mNumAcquired - mPendingRelease.size());