cc: Add UMA stats for record and raster time.

cc/layers/picture_layer.cc

Index: cc/layers/picture_layer.cc
diff --git a/cc/layers/picture_layer.cc b/cc/layers/picture_layer.cc
index d41b541585cd8838ab70751015437696d50a4e18..e2ff13f44a488f575608d1e65ac5a27f6a7a1e1f 100644
--- a/cc/layers/picture_layer.cc
+++ b/cc/layers/picture_layer.cc
@@ -5,6 +5,8 @@
 #include "cc/layers/picture_layer.h"
 
 #include "base/auto_reset.h"
+#include "base/metrics/histogram_macros.h"
+#include "base/timer/elapsed_timer.h"
 #include "cc/layers/content_layer_client.h"
 #include "cc/layers/picture_layer_impl.h"
 #include "cc/resources/display_list_recording_source.h"
@@ -136,6 +138,7 @@ bool PictureLayer::Update(ResourceUpdateQueue* queue,
                layer_tree_host()->source_frame_number());
   devtools_instrumentation::ScopedLayerTreeTask update_layer(
       devtools_instrumentation::kUpdateLayer, id(), layer_tree_host()->id());
+  base::ElapsedTimer timer;
 
   // Calling paint in WebKit can sometimes cause invalidations, so save
   // off the invalidation prior to calling update.
@@ -166,6 +169,13 @@ bool PictureLayer::Update(ResourceUpdateQueue* queue,
     recording_invalidation_.Clear();
   }
 
+  base::TimeDelta elapsed = timer.Elapsed();
+  UMA_HISTOGRAM_COUNTS("Renderer4.PictureLayerUpdateUs",
+                       elapsed.InMicroseconds());
+  UMA_HISTOGRAM_COUNTS(
+      "Renderer4.PictureLayerUpdatePixelsPerMs",
+      visible_layer_rect.size().GetArea() / elapsed.InMillisecondsF());

[enne (OOO), 2015/04/08 20:18:45]

visible layer rect is an inaccurate numerator.  You're really looking for
recording area, yeah?

Maybe you should sum up the total pictures created and their areas?

[jbroman, 2015/04/08 20:37:42]

I'm hoping to avoid using an area that has different meaning before and after
slimming paint v2. I agree that this metric isn't great.

I'm not 100% sure I understand what you're suggesting here. Are the bounds of
the pictures really guaranteed to meaningfully represent the invalidated area we
asked to record? (For example, if I record a small rect somewhere, but it
happens to be be filled with a much larger rect, won't this radically
overestimate the recorded area?)

The visible layer rect is what RasterizeAndRecordBenchmark uses, though I
realize in that case the recording is always the full visible layer size. Is
that why it's inapplicable here?

If we can't find a good option, we might also just consider dropping this one
and only tracking the per-layer record time.

[enne (OOO), 2015/04/08 21:03:49]

No, the bounds are not the invalidated area.  The bounds are the recorded area. 
What I want to know is "if I say record WxH bounds in Blink, how fast is that?".
 I think that's the unit that we can meaningfully compare?
That's exactly it.
Record time (in my experience) is about number of calls to paint and about the
size of the paint.  Per-layer time will give inflated numbers for multiple
record calls.

+
   return updated;
 }