cc: Heuristic for Renderer latency recovery

cc/trees/proxy_timing_history.cc

Index: cc/trees/proxy_timing_history.cc
diff --git a/cc/trees/proxy_timing_history.cc b/cc/trees/proxy_timing_history.cc
index 90abad1632f585c407106d556d52d7c3de5ad2cf..956eb81c6d855c85d6a1012537401ab5e05f70d5 100644
--- a/cc/trees/proxy_timing_history.cc
+++ b/cc/trees/proxy_timing_history.cc
@@ -9,7 +9,7 @@
 const size_t kDurationHistorySize = 60;
 const double kCommitAndActivationDurationEstimationPercentile = 50.0;
 const double kDrawDurationEstimationPercentile = 100.0;
-const int kDrawDurationEstimatePaddingInMicroseconds = 0;
+const int kDrawDurationEstimatePaddingInMicroseconds = 1000;

[mithro-old, 2015/05/27 04:40:15]

Why this change?

This is also a magic number, why do we pad the DrawDurationEstimate with 1ms?

This also feels like the wrong place to be doing any padding?

[brianderson, 2015/05/27 23:22:32]

I'll move the padding to the scheduler so it's more obvious. I added the padding
to make races with the DisplayScheduler's deadline less likely. We don't account
for IPC propogation/descheduling delays anywhere else at the moment.

I can move this to a separate patch.

Before this patch, if we lost the race then we'd just go into a high latency
mode. If we lose the race with this patch though, we might try to recovery the
latency and lose the race over and over again.

I should probably add logic to make latency recovery less likely in the future
if it has failed in the past...

 
 namespace cc {