Add synthetic delay points for latency testing

cc/resources/raster_worker_pool.cc

Index: cc/resources/raster_worker_pool.cc
diff --git a/cc/resources/raster_worker_pool.cc b/cc/resources/raster_worker_pool.cc
index 67c548f19df92fe1f0990475689a157718a7d392..65da1153de09b98965a946a18509e088259327e1 100644
--- a/cc/resources/raster_worker_pool.cc
+++ b/cc/resources/raster_worker_pool.cc
@@ -4,6 +4,7 @@
 
 #include "cc/resources/raster_worker_pool.h"
 
+#include "base/debug/trace_event_synthetic_delay.h"
 #include "base/json/json_writer.h"
 #include "base/metrics/histogram.h"
 #include "base/values.h"
@@ -18,6 +19,10 @@ namespace cc {
 
 namespace {
 
+// Synthetic delay for raster tasks that are required for activation. Global to
+// avoid static initializer on critical path.
+base::debug::TraceEventSyntheticDelay* g_raster_required_for_activation_delay;
+
 // Subclass of Allocator that takes a suitably allocated pointer and uses
 // it as the pixel memory for the bitmap.
 class IdentityAllocator : public SkBitmap::Allocator {
@@ -191,6 +196,7 @@ class RasterWorkerPoolTaskImpl : public internal::RasterWorkerPoolTask {
     }
 
     ChangeBitmapConfigIfNeeded(bitmap, buffer);
+    g_raster_required_for_activation_delay->End();
 
     return true;
   }
@@ -466,6 +472,9 @@ RasterWorkerPool::RasterWorkerPool(ResourceProvider* resource_provider,
       client_(NULL),
       resource_provider_(resource_provider),
       weak_ptr_factory_(this) {
+  g_raster_required_for_activation_delay =
+      base::debug::TraceEventSyntheticDelay::Lookup(
+          "cc.RasterRequiredForActivation");

[reveman, 2013/12/12 19:29:43]

what if this is done on two threads at the same time? can we use a LazyInstance
to make this thread safe?

 }
 
 RasterWorkerPool::~RasterWorkerPool() {
@@ -487,6 +496,14 @@ void RasterWorkerPool::SetRasterTasks(RasterTask::Queue* queue) {
   raster_tasks_.swap(queue->tasks_);
   raster_tasks_required_for_activation_.swap(
       queue->tasks_required_for_activation_);
+  // Note: a raster task from the previous task set may call End() even after
+  // this reset. When this happens, the synthetic delay will get activated
+  // early, increasing the total activation delay the length of one raster
+  // task. Because tasks from the old set may still be needed to activate the
+  // new tree, we can't entirely discount them. This is therefore a compromise
+  // to ensure the activation delay is always at least as long as configured.
+  g_raster_required_for_activation_delay->ResetAndBeginMultiple(
+      raster_tasks_required_for_activation_.size());

[reveman, 2013/12/12 19:29:43]

This seems a bit too flaky to me. Could we do this as part of the
RasterFinishedWorkerPoolTaskImpl task instead and never reset it?

 }
 
 bool RasterWorkerPool::IsRasterTaskRequiredForActivation(