From 277142c594918f828712a2412d3f95164eebffeb Mon Sep 17 00:00:00 2001 From: Vishnu Nair Date: Tue, 5 Jan 2021 18:35:29 -0800 Subject: SurfaceFlinger: Support out of order transactions With BLAST, buffers are submitted via transactions and they are subjected to the same transaction queueing logic - transactions from a client must be applied in the order they came in. This poses a problem when clients use multiple blast adapters. Transactions from one window can get queued up if the buffer is not ready to be presented, preventing transactions from another window to be applied in a timely manner. We fix this by using a different apply token for every bast adapter so their transactions are handled independently. Bug: b/176411039, b/168917217 Test: atest BlastBufferQueueTest Test: YouTube minimize video and scroll, notice scrolling is at 60/90fps Change-Id: I0005dfa3c221a2b33545e39af16ae4b1ef08d269 --- libs/gui/BLASTBufferQueue.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'libs/gui/BLASTBufferQueue.cpp') diff --git a/libs/gui/BLASTBufferQueue.cpp b/libs/gui/BLASTBufferQueue.cpp index 89de629442..eaa47f9680 100644 --- a/libs/gui/BLASTBufferQueue.cpp +++ b/libs/gui/BLASTBufferQueue.cpp @@ -371,7 +371,7 @@ void BLASTBufferQueue::processNextBufferLocked(bool useNextTransaction) { mPendingTransactions.end()); if (applyTransaction) { - t->apply(); + t->setApplyToken(mApplyToken).apply(); } BQA_LOGV("processNextBufferLocked size=%dx%d mFrameNumber=%" PRIu64 -- cgit v1.2.3-59-g8ed1b