summaryrefslogtreecommitdiff
path: root/libs/gui/BufferQueueThreadState.cpp
diff options
context:
space:
mode:
author Ady Abraham <adyabr@google.com> 2020-09-30 19:19:27 -0700
committer Ady Abraham <adyabr@google.com> 2020-10-05 11:20:47 -0700
commit55fa7272747ba308525e2837489637ec09eb9cdf (patch)
tree830d6630139907c5ad37a44bd92ca36c2a9f56b2 /libs/gui/BufferQueueThreadState.cpp
parent97651d23e882aa8cb24d1a6b45808a549474bcb6 (diff)
SurfaceFlinger: decouple EventThread from SF wakeup
Today we have two instances of EventThread: 1. 'app' - used to wake up Choreographer clients 2. 'sf' - used to wake up SF mian thead *and* Choreographer clients that uses sf instance Now this creates an ambiguity when trying to reason about the expected vsync time and deadline of 'sf' EventThread: - SF wakes up sfWorkDuration before a vsync and targets that vsync - Choreographer users wakes up with SF main thread but targets the vsync that happens after the next SF wakeup. To resolve this ambiguity we are decoupling SF wakeup from 'sf' EventThread. This means that Choreographer clients that uses 'sf' instance will keep using the EventThread but SF will be waking up directly by a callback with VSyncDispatch. This allows us to correct the expected vsync and deadline for both. Test: Interacting with the device and observe systraces Test: new unit test added to SF suite Bug: 166302754 Change-Id: I76d154029b4bc1902198074c33d38ff030c4601b
Diffstat (limited to 'libs/gui/BufferQueueThreadState.cpp')
0 files changed, 0 insertions, 0 deletions