From cf2f21fd82d1f95b20077fd9a10aeaa6eb4c202e Mon Sep 17 00:00:00 2001 From: Robert Carr Date: Tue, 30 Nov 2021 14:47:02 -0800 Subject: 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 --- libs/gui/BLASTBufferQueue.cpp | 3 +++ 1 file changed, 3 insertions(+) (limited to 'libs/gui/BLASTBufferQueue.cpp') 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()); -- cgit v1.2.3-59-g8ed1b