SF: handle long waiting Layer sync point
When Layer transaction deferred
it wait for barrier layer's specific frame.
When the target frame is delayed for a long time, e.g. 5 min
the deferred transaction layer may queue up in mPendingStates,
may up to 20000 in real case.
When the target frame come, it will loop through mPendingStates
and call popPendingState with mPendingStates.removeAt(0);
which is an inefficient operator for Vector, which cause SWT.
Change to use std::deque for mPendingStates & mPendingStatesSnapshot
Add sync point timeout debug log.
Bug: 170690571
Test: boot up
Test: LayerUpdateTest
Test: setting pages in/out
Change-Id: I17f3751836574c3691c7e5a1e6d2ea6c3fcd3903
diff --git a/services/surfaceflinger/Layer.cpp b/services/surfaceflinger/Layer.cpp
index 90396dd..4f68fa6 100644
--- a/services/surfaceflinger/Layer.cpp
+++ b/services/surfaceflinger/Layer.cpp
@@ -816,7 +816,8 @@
// to be applied as per normal (no synchronization).
mCurrentState.barrierLayer_legacy = nullptr;
} else {
- auto syncPoint = std::make_shared<SyncPoint>(mCurrentState.barrierFrameNumber, this);
+ auto syncPoint = std::make_shared<SyncPoint>(mCurrentState.barrierFrameNumber, this,
+ barrierLayer);
if (barrierLayer->addSyncPoint(syncPoint)) {
std::stringstream ss;
ss << "Adding sync point " << mCurrentState.barrierFrameNumber;
@@ -841,7 +842,7 @@
ATRACE_CALL();
*stateToCommit = mPendingStates[0];
- mPendingStates.removeAt(0);
+ mPendingStates.pop_front();
ATRACE_INT(mTransactionName.c_str(), mPendingStates.size());
}
@@ -880,6 +881,7 @@
mRemoteSyncPoints.pop_front();
} else {
ATRACE_NAME("!frameIsAvailable");
+ mRemoteSyncPoints.front()->checkTimeoutAndLog();
break;
}
} else {