Refactor obtaining display in SF main thread
Getting the display requires the SF state lock, and this can
cause deadlocks if this work is done on a binder thread. The
eventual goal is to place all the work in renderScreenImpl on the
binder thread, so reshuffling where we get the display to an area
where we already go onto the main thread will reduce lock contention.
Additional cleanups to remove overloaded renderScreenImpl for
testable SF suite.
Bug: b/294936197
Test: atest SurfaceFlinger_test
Test: atest CompositionTest
Test: presubmit
Change-Id: I95697a2508a9d936ac9689430d9060c49ed3f039
diff --git a/services/surfaceflinger/tests/unittests/CompositionTest.cpp b/services/surfaceflinger/tests/unittests/CompositionTest.cpp
index 0ddddbd..98f1687 100644
--- a/services/surfaceflinger/tests/unittests/CompositionTest.cpp
+++ b/services/surfaceflinger/tests/unittests/CompositionTest.cpp
@@ -215,7 +215,7 @@
HAL_PIXEL_FORMAT_RGBA_8888, 1,
usage);
- auto future = mFlinger.renderScreenImpl(std::move(renderArea), getLayerSnapshots,
+ auto future = mFlinger.renderScreenImpl(mDisplay, std::move(renderArea), getLayerSnapshots,
mCaptureScreenBuffer, regionSampling);
ASSERT_TRUE(future.valid());
const auto fenceResult = future.get();