media/gpu: restore some of the reformatting done during migration to media/gpu.

media/gpu/vaapi_jpeg_decode_accelerator.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/gpu/vaapi_jpeg_decode_accelerator.h"
 
 #include <stddef.h>
 #include <string.h>
 
 #include <memory>
@@ skipping 10 matching lines @@
 #include "media/gpu/shared_memory_region.h"
 #include "media/gpu/vaapi_picture.h"
 #include "third_party/libyuv/include/libyuv.h"
 
 namespace media {
 
 namespace {
 // UMA errors that the VaapiJpegDecodeAccelerator class reports.
 enum VAJDADecoderFailure {
   VAAPI_ERROR = 0,
+  // UMA requires that max passed to UMA_HISTOGRAM_ENUMERATION must be greater
+  // than 1.

[Mark Dittmer, 2016/05/12 14:13:51]

I still don't understand this comment. We have:

VAJDADecoderFailure {
 0: VAAPI_ERROR,
 1: VAJDA_DECODER_FAILURES_MAX,
}

The "MAX" here is NOT greater than 1. Why do we have a comment suggesting that
it is?

[Pawel Osciak, 2016/05/13 06:07:22]

Please see below.

   VAJDA_DECODER_FAILURES_MAX,
 };
 
 static void ReportToUMA(VAJDADecoderFailure failure) {
   UMA_HISTOGRAM_ENUMERATION("Media.VAJDA.DecoderFailure", failure,
                             VAJDA_DECODER_FAILURES_MAX + 1);

[Mark Dittmer, 2016/05/12 14:13:51]

Should the above-mentioned comment go here instead? That would make a lot more
sense to me.

[Pawel Osciak, 2016/05/13 06:07:22]

Yeah, sorry, the reason is that it's gotten a bit more complicated now after the
migration to media/gpu.

There are two issues actually. First of all, the original issue in UMA, where we
can't have just one bucket in a histogram, please see
https://bugs.chromium.org/p/chromium/issues/detail?id=549054#c6 for explanation.
The second issue is that there is a presubmit hook in media/, which didn't
trigger before we moved this to media/, which requires a particular style for
UMA max values in media/, please see commit message for http://crrev.com/254209.

So with that, normally we'd say:
enum VAJDADecoderFailure {
  VAAPI_ERROR = 0,
  VAJDA_DECODER_FAILURES_MAX = VAAPI_ERROR,
};

UMA_HISTOGRAM_ENUMERATION(..., VAJDA_DECODER_FAILURES_MAX + 1);


However, this hits the first issue. If we instead did:

enum VAJDADecoderFailure {
  VAAPI_ERROR = 0,
  VAJDA_DECODER_FAILURES_MAX = 2,
};

UMA_HISTOGRAM_ENUMERATION(..., VAJDA_DECODER_FAILURES_MAX);

That would have triggered the second check. But I just thought of a different
solution. I'll submit it as a separate CL to keep this as a cosmetic-only
change.

 }
 
 static unsigned int VaSurfaceFormatForJpeg(
     const media::JpegFrameHeader& frame_header) {
   // The range of sampling factor is [1, 4]. Pack them into integer to make the
   // matching code simpler. For example, 0x211 means the sampling factor are 2,
   // 1, 1 for 3 components.
   unsigned int h = 0, v = 0;
   for (int i = 0; i < frame_header.num_components; i++) {
     DCHECK_LE(frame_header.components[i].horizontal_sampling_factor, 4);
@@ skipping 266 matching lines @@
   decoder_task_runner_->PostTask(
       FROM_HERE, base::Bind(&VaapiJpegDecodeAccelerator::DecodeTask,
                             base::Unretained(this), base::Passed(&request)));
 }
 
 bool VaapiJpegDecodeAccelerator::IsSupported() {
   return VaapiWrapper::IsJpegDecodeSupported();
 }
 
 }  // namespace media