cc: Plumbing for impl thread micro benchmarks

cc/debug/micro_benchmark_controller.cc

Index: cc/debug/micro_benchmark_controller.cc
diff --git a/cc/debug/micro_benchmark_controller.cc b/cc/debug/micro_benchmark_controller.cc
index 6e34e481698a0b0e7055848f7032153e5a2a932f..23e81e6ca9bc494fd8e06d318c7140f791ce068a 100644
--- a/cc/debug/micro_benchmark_controller.cc
+++ b/cc/debug/micro_benchmark_controller.cc
@@ -7,10 +7,12 @@
 #include <string>
 
 #include "base/callback.h"
+#include "base/message_loop/message_loop_proxy.h"
 #include "base/values.h"
 #include "cc/debug/picture_record_benchmark.h"
 #include "cc/debug/unittest_only_benchmark.h"
 #include "cc/trees/layer_tree_host.h"
+#include "cc/trees/layer_tree_host_impl.h"
 
 namespace cc {
 
@@ -43,7 +45,8 @@ class IsDonePredicate {
 }  // namespace
 
 MicroBenchmarkController::MicroBenchmarkController(LayerTreeHost* host)
-    : host_(host) {
+    : host_(host),
+      main_controller_message_loop_(base::MessageLoopProxy::current().get()) {
   DCHECK(host_);
 }
 
@@ -63,12 +66,24 @@ bool MicroBenchmarkController::ScheduleRun(
   return false;
 }
 
+void MicroBenchmarkController::ScheduleImplBenchmarks(
+    LayerTreeHostImpl* host_impl) {
+  for (ScopedPtrVector<MicroBenchmark>::iterator it = benchmarks_.begin();
+       it != benchmarks_.end();
+       ++it) {
+    scoped_ptr<MicroBenchmarkImpl> benchmark_impl =
+        (*it)->CreateBenchmarkImpl(main_controller_message_loop_);

[enne (OOO), 2013/11/12 01:09:36]

So if you have a MicroBenchmarkImpl that doesn't complete immediately, it will
create a second MicroBenchmarkImpl on the next commit? That seems a little
unexpected here.  Should each MicroBenchmark only get one outstanding
MicroBenchmarkImpl? Or, is there some other use case?

[vmpstr, 2013/11/12 17:51:38]

That's a good point. I mean it _could_ happen that we need an impl side
benchmark on every commit for several commits, but rasterize and record isn't
one of these cases. I renamed this to CreateBenchmarkImplIfNeeded and the
rasterize and record benchmark should only return a benchmark on the first call
and later return null. Either that or we can mark each MicroBenchmark as already
processed for impl benchmarks. Wdyt?

[enne (OOO), 2013/11/12 19:22:56]

Yeah, I'm not sure what the right thing to do here is.

What about having the controller have a map of benchmark to benchmark impl. 
Calling CreateBenchmarkImpl adds it to the map.  Being cleaned up removes it. 
CreateBenchmarkImpl can then only get called if it's not already in the map?
That way individual benchmarks don't have to manage this.

[vmpstr, 2013/11/12 20:20:38]

I went with just keeping the state in the microbenchmark base class. Now
GetBenchmarkImpl is non-virtual and it updates the state of whether we grabbed
the impl part or not. CreateBenchmarkImpl is now protected to avoid accidentally
creating it directly. I kind of prefer this approach over a separate map that
needs to be maintained in the controller. Let me know if this works for you.

+    if (benchmark_impl.get())
+      host_impl->ScheduleMicroBenchmark(benchmark_impl.Pass());
+  }
+}
+
 void MicroBenchmarkController::DidUpdateLayers() {
   for (ScopedPtrVector<MicroBenchmark>::iterator it = benchmarks_.begin();
        it != benchmarks_.end();
        ++it) {
-    DCHECK(!(*it)->IsDone());
-    (*it)->DidUpdateLayers(host_);
+    if (!(*it)->IsDone())

[vmpstr, 2013/11/09 00:41:41]

If the main thread benchmark was waiting for the impl one to finish, and the
impl finished, then MicroBenchmarkController never had a chance to clean it up.
This means we might have valid cases where DidUpdateLayers is called while there
are benchmarks in the done state.

+      (*it)->DidUpdateLayers(host_);
   }
 
   CleanUpFinishedBenchmarks();