Calculate workload target using original frame deadline

The target work duration in HWUI ADPF is sometimes incorrect, and
is more often incorrect during buffer stuffing recovery due to the
exposure of new jank. The issue causes CPU clock frequencies to
decrease too much, and cause potential jank in subequent frames.

The original frame deadline should be used instead in calculating
the workload target deadline when triple buffered because even when
the deadline is pushed later during buffer stuffing, the throughput
requirements remain the same.

Also fixes a misordering in FrameInfoNames that was inconsistent
with FrameInfo and FrameMetrics.

Bug: b/389939827
Test: atest JankTracker
Test: presubmit, perfetto traces w/ and w/o buffer stuffing recovery
Flag: com.android.graphics.hwui.flags.calc_workload_orig_deadline
Change-Id: I2e3da6ee927d20fcbc9299ab5eda5732660d7246

1 files changed, 7 insertions, 1 deletions

diff --git a/libs/hwui/renderthread/CanvasContext.cpp b/libs/hwui/renderthread/CanvasContext.cpp
index b36b8be10779..e3e393c4fdfb 100644
--- a/libs/hwui/renderthread/CanvasContext.cpp
+++ b/libs/hwui/renderthread/CanvasContext.cpp
@@ -789,7 +789,13 @@ void CanvasContext::draw(bool solelyTextureViewUpdates) {
     int64_t frameDeadline = mCurrentFrameInfo->get(FrameInfoIndex::FrameDeadline);
     int64_t dequeueBufferDuration = mCurrentFrameInfo->get(FrameInfoIndex::DequeueBufferDuration);
 
-    mHintSessionWrapper->updateTargetWorkDuration(frameDeadline - intendedVsync);
+    if (Properties::calcWorkloadOrigDeadline()) {
+        // Uses the unmodified frame deadline in calculating workload target duration
+        mHintSessionWrapper->updateTargetWorkDuration(
+                mCurrentFrameInfo->get(FrameInfoIndex::WorkloadTarget));
+    } else {
+        mHintSessionWrapper->updateTargetWorkDuration(frameDeadline - intendedVsync);
+    }
 
     if (didDraw) {
         int64_t frameStartTime = mCurrentFrameInfo->get(FrameInfoIndex::FrameStartTime);