Add Histogram Macros to Skia

include/config/SkUserConfig.h

 
 /*
  * Copyright 2006 The Android Open Source Project
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 
 #ifndef SkUserConfig_DEFINED
@@ skipping 135 matching lines @@
 
 /* The PDF generation code uses Path Ops to handle complex clipping paths,
  * but at this time, Path Ops is not release ready yet. So, the code is
  * hidden behind this #define guard. If you are feeling adventurous and
  * want the latest and greatest PDF generation code, uncomment the #define.
  * When Path Ops is release ready, the define guards and this user config
  * define should be removed entirely.
  */
 //#define SK_PDF_USE_PATHOPS_CLIPPING
 
+/* Skia makes use of histogram logging macros to trace the frequency of
+ * events. By default, Skia provides no-op versions of these macros.
+ * Skia consumers can provide their own definitions of these macros to
+ * integrate with their histogram collection backend.

[mtklein, 2016/02/02 00:55:23]

What are the rules of evolving these things and breaking Chrome?

Can we just change their types and value-range willy nilly?
E.g. can we upgrade a bool to an enum?  Can we add more fields to an enum
without breaking Chrome?  Does changing a field's name matter?  

Does the data logged to these fields end up in some sort of query interface? 
What other sorts of histograms does Chrome support  (linear bucketing and
exponential bucketing for floats?), and how evolvable are they? 

Do the strings we pass for name need to be literals, or just compile time
constants, or any char*?   E.g. can we pass SkString::c_str() as a temporary?

[ericrk, 2016/02/02 19:36:28]

Chrome does have tables which assign each metric an owner, a type, as well as a
value to string mapping (in the case of enums). If a metric doesn't line up with
this table, stats may stop being collected (although chrome shouldn't experience
any runtime issues).

It's also ok for stats to not appear in this table - in this case they will
still be collected locally (and viewable in chrome://histograms), but won't be
uploaded.

To work around this, I'd probably recommend that changes to values in Skia
typically come with a name change - this will de-couple changes in Skia/Chrome,
allowing update CLs to land separately with no risk of breakage or need for
tight coordination. Changes in Skia will still be testable and should work fine,
they just won't be uploaded to Chrome's servers until a corresponding Chrome
change goes in.
Yup - google internal only though - will send you a link.
See chrome's base/metrics/histogram_macros.h for a full list, but to give an
overview, chrome has:

- times - used for logging the time something takes - customizable min/max range
used for bucketing.

- counts - used for logging the number of times something happens - allows for
min/max

- percentages - used for logging percentages :P - bucketized as integers 1-100

Currently no real float or exponential bucketing, although you could convert
floats to large ints and go from there.
The function eventually allows for either const std::string& or const char*. The
function does not use the value past the lifetime of the call, nor does it
assume it's the same every time - feel free to use any char*, even a temporary
one.

+ */
+//#define SK_HISTOGRAM_BOOLEAN(name, value)
+//#define SK_HISTOGRAM_ENUMERATION(name, value, boundary_value)
+
 #endif