Initial attempt at counting layers in the compositor thread.

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index 088d56df6a7a0c4f67f790f8e42e6433b9d7f590..53342292aea24d0d638c472af60fae77a5334601 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -114,6 +114,10 @@ unsigned GetMapImageTextureTarget(cc::ContextProvider* context_provider) {
   return GL_TEXTURE_2D;
 }
 
+void LayerCounter(size_t* counter, cc::LayerImpl* /* layer */) {

[danakj, 2014/07/10 18:03:41]

we don't comment out parameter names in chrome

+  (*counter)++;
+}
+
 }  // namespace
 
 namespace cc {
@@ -255,7 +259,8 @@ LayerTreeHostImpl::LayerTreeHostImpl(
 #endif
       shared_bitmap_manager_(manager),
       id_(id),
-      transfer_buffer_memory_limit_(0u) {
+      transfer_buffer_memory_limit_(0u),
+      num_layers_(0u) {
   DCHECK(proxy_->IsImplThread());
   DidVisibilityChange(this, visible_);
   animation_registrar_->set_supports_scroll_animations(
@@ -1099,6 +1104,16 @@ DrawResult LayerTreeHostImpl::PrepareToDraw(FrameData* frame) {
   }
   need_to_update_visible_tiles_before_draw_ = true;
 
+  {
+    // Count the number of layers.  See http://crbug.com/253919
+    // A large number of layers might slow down rendering.
+    num_layers_ = 0;

[danakj, 2014/07/10 18:03:41]

While I love tests, I don't think we need to add a member variable to this class
that is only for unit tests. Generally we haven't tested UMA counts with unit
tests, which maybe is bad, idk. If we want to test this, we should find a way to
test the computation without requiring a new member var on this class.

The active_tree_->layer_id_map_.size() has the number of layers in the active
tree, doesn't it?

[Ian Vollick, 2014/07/10 18:09:50]

Ah, cool! That's a great idea. If we can use that size rather than computing the
# by hand here, then we def don't need tests.

[dneto, 2014/07/10 18:44:16]

Yes, that's smart!  I don't know the data structures well enough yet. :-)

+    LayerTreeHostCommon::CallFunctionForSubtree<LayerImpl>(
+        active_tree_->root_layer(), base::Bind(LayerCounter, &num_layers_));

[Ian Vollick, 2014/07/10 03:16:23]

I'm a bit worried about doing an extra tree walk every frame to gather this
number, especially since this number can only change at commit time when we
update the trees.

If mucking with the tree synchronizer is ugly, perhaps we could update
num_layers_ in ::CommitComplete and just report it here (so that we get the
right weighting)?

[dneto, 2014/07/10 18:44:16]

I'll rework it one way or another.

+    UMA_HISTOGRAM_CUSTOM_COUNTS(
+        "Compositing.NumLayers", num_layers_, 1, 1000, 50);

[dneto, 2014/07/10 01:29:03]

Also not sure if range of 1000 and width-20 buckets is the most useful view. 
Alternate would be standard histogram of up to 100.

[Ian Vollick, 2014/07/10 03:16:22]

This is probably ok. width-10 buckets might be nice to give some more resolution
for small trees (where we'll likely have the most samples), but I'm not sure it
would make much difference.

[dneto, 2014/07/10 18:44:16]

Ok.   I'll make width-10 buckets with a range up to 1000.  I was only concerned
about space but it looks like the histogram implementation effectively uses a
std::vector<int> sized to the number of buckets. So 100 ints shouldn't be a
problem.

+  }
+
   bool ok = active_tree_->UpdateDrawProperties();
   DCHECK(ok) << "UpdateDrawProperties failed during draw";