Refine WinSAT histogram bounds and rescale so the results are integers.

content/gpu/gpu_info_collector_win.cc

Index: content/gpu/gpu_info_collector_win.cc
diff --git a/content/gpu/gpu_info_collector_win.cc b/content/gpu/gpu_info_collector_win.cc
index fa26c3571ece2f509543ad78616245528cd0edb5..57ee1d8619e1a64a5986b9af67ab3614923b0b90 100644
--- a/content/gpu/gpu_info_collector_win.cc
+++ b/content/gpu/gpu_info_collector_win.cc
@@ -136,12 +136,10 @@ content::GpuPerformanceStats RetrieveGpuPerformanceStats() {
   if (stats.gaming == 0.0)
     LOG(ERROR) << "Could not read gaming score from assessment results.";
 
-  UMA_HISTOGRAM_CUSTOM_COUNTS("GPU.WinSAT.OverallScore",
-                              stats.overall, 0.0, 50.0, 50);
-  UMA_HISTOGRAM_CUSTOM_COUNTS("GPU.WinSAT.GraphicsScore",
-                              stats.graphics, 0.0, 50.0, 50);
-  UMA_HISTOGRAM_CUSTOM_COUNTS("GPU.WinSAT.GamingScore",
-                              stats.gaming, 0.0, 50.0, 50);
+  UMA_HISTOGRAM_ENUMERATION("GPU.WinSAT.OverallScore", stats.overall * 10, 200);

[jar (doing other things), 2012/08/04 02:04:46]

In addition to my comment below....

I was surprised first of all to see that you wanted 200 buckets.  That is
generally larger than most folks would find useful.... but I don't fully
understand your data, and your expected distribution.

Looking at the old code, it seemed to suggest that teh interesting values of
"stats.overall" was going to be values between 0 and 50.  In addition, since you
said you had a total of 50 buckets... you got pretty close to one bucket per
unit interval (subtle reason why it was not exact... and you probably had a top
end interval like 48-50 as one bucket).

The new range suggests that you want to see values where stats.overall * 10 is
in the range of 0-200.  Hence you're now only interested in stats.overall in the
range of 0 to 20 (rather than your previous interest up to 50).  ...and in
addition, you wanted that smaller range broken up into a super fine grain list
of 200 separate buckets.

I took a look at the collected data, and can see that it is it is indeed super
rare to even go beyond 7.

As a result, it probably makes sense that you are now looking only at the range
of 0-20 (scaled by a factor of 10).

...however... the "cool" way to do this is not to have a giant linear histogram
(re: using HISTOGRAM_ENUMERATION), but instead let the magic of the exponential
histogram help you.

I'd suggest using:

UMA_HISTOGRAM_CUSTOM_COUNTS("name", overall * 10, 1, 200, 50);

That will give you a LOT of resolution down near the lower end of the range
1-200, but not waste buckets looking at narrow details in the upper range.

YMMV... but 200 buckets is a lot of buckets... and probably not needed (and the
suggestion above will only gather 50 buckets).

[dtu, 2012/08/06 21:41:47]

Done.

+  UMA_HISTOGRAM_ENUMERATION("GPU.WinSAT.GraphicsScore",
+                            stats.graphics * 10, 200);
+  UMA_HISTOGRAM_ENUMERATION("GPU.WinSAT.GamingScore", stats.gaming * 10, 200);

[jar (doing other things), 2012/08/04 02:04:46]

Best practice, when changing the parameters by which you defined a histogram, is
to change the name to a new name.  This way, if you look at "All" results from
all versions, you won't get a confusing conflation of the two histograms.

Common practice is just to add a trailing "2" or such to the "old" name to
define a new name.

You should indeed land the old names in our XML file, so that we can see old
data.  I've temporarily landed GPU.WiinSat_OverallScore so you can now glance at
what data we've already collected.

[dtu, 2012/08/06 21:41:47]

Done.

 
   UMA_HISTOGRAM_TIMES("GPU.WinSAT.ReadResultsFileTime",
                       base::TimeTicks::Now() - start_time);