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 c3738e594734e6b5fd7df5d2fe9e6ca0191ba22e..862f806b741ef8ff3cb62d40da0cf0cf35f3d0a3 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -1101,6 +1101,11 @@ DrawResult LayerTreeHostImpl::PrepareToDraw(FrameData* frame) {
   }
   need_to_update_visible_tiles_before_draw_ = true;
 
+  // Use a bucket width of 10 (i.e. 1000/100) to better

[danakj, 2014/07/10 21:27:44]

I'm not sure what this comment is saying? That you could change the 1 to a 10?
This histogram will be out in the wild and show up on dashboards etc, so we
won't really be able to change it once we ship it.

[dneto, 2014/07/11 15:23:30]

The 1 is min, the 1000 is max, and 10 is the number of buckets.  Vollick
suggested that chrome wouldn't perform well at all beyond 200, and expected the
vast majority of frames to have very few layers.  So we wanted more granularity
at the lower end.  
The canned counting histograms are:
     (1,1000000,50):  probably too large a range
     (1,100,50):      good granularity, but maybe not enough range at the high
end? 
     (1,10000,50):    poor granularity, and probably overkill.
I don't have good intuition on the distribution, so I'm looking for guidance on
the numbers, or on expressing intent in the comment.

[danakj, 2014/07/11 15:27:20]

Ok how about 1, 400, 20? And we can drop the comment?

+  // capture the expected case where there are few layers.
+  UMA_HISTOGRAM_CUSTOM_COUNTS(
+      "Compositing.NumActiveLayers", active_tree_->NumLayers(), 1, 1000, 100);

[dneto, 2014/07/10 21:20:11]

This is the corrected name for the UMA, matching the one in the histogram.xml
file.

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