Use SkJpegEncoder in gfx jpeg_codec

ui/gfx/codec/jpeg_codec.h

Index: ui/gfx/codec/jpeg_codec.h
diff --git a/ui/gfx/codec/jpeg_codec.h b/ui/gfx/codec/jpeg_codec.h
index fbc07903ebc8a5cae6f5b6b36dbacc119c91632f..0ac772e36d0b604088cb318ed9f3201e0d4a1337 100644
--- a/ui/gfx/codec/jpeg_codec.h
+++ b/ui/gfx/codec/jpeg_codec.h
@@ -10,6 +10,8 @@
 #include <memory>
 #include <vector>
 
+#include "third_party/skia/include/core/SkImageInfo.h"
+#include "third_party/skia/include/core/SkPixmap.h"
 #include "ui/gfx/codec/codec_export.h"
 
 class SkBitmap;
@@ -35,19 +37,20 @@ class CODEC_EXPORT JPEGCodec {
     FORMAT_SkBitmap
   };
 
-  // Encodes the given raw 'input' data, with each pixel being represented as
-  // given in 'format'. The encoded JPEG data will be written into the supplied
-  // vector and true will be returned on success. On failure (false), the
-  // contents of the output buffer are undefined.
+  // Encodes the given raw 'input' pixmap, which includes a pointer to pixels
+  // as well as information describing the pixel format. The encoded JPEG data
+  // will be written into the supplied vector and true will be returned on
+  // success. On failure (false), the contents of the output buffer are
+  // undefined.
   //
   // w, h: dimensions of the image
   // row_byte_width: the width in bytes of each row. This may be greater than
   //   w * bytes_per_pixel if there is extra padding at the end of each row
   //   (often, each row is padded to the next machine word).
   // quality: an integer in the range 0-100, where 100 is the highest quality.
-  static bool Encode(const unsigned char* input, ColorFormat format,
-                     int w, int h, int row_byte_width,
-                     int quality, std::vector<unsigned char>* output);
+  static bool Encode(const SkPixmap& input,

[dcheng, 2017/06/12 20:35:43]

Any reason not to use SkBitmap? This avoids all the callers having to call
peekBitmap() and (potentially) checking the result.

[msarett1, 2017/06/12 20:57:56]

This is a good question, especially because there are a fair amount of
duplicated peekPixels() calls in the clients.

SkBitmap is holds a ref to its pixels.  SkPixmap is a more lightweight container
for a pointer and some info.

SkPixmap is the preferred API (from a Skia perspective) and is more versatile. 
Ex: if we don't start with a SkBitmap, we don't need to install into an
SkBitmap.  I think for these reasons we definitely want a version that takes
SkPixmap.

I didn't write a version that takes SkBitmap because Skia is trying to move
clients away from using SkBitmap... but I can see it is convenient for a lot of
callers.

I'm ok with adding another entry point that takes an SkBitmap (and simplifying
some of the callers).  What do you think?

[dcheng, 2017/06/12 21:00:15]

Adding an overload is fine. I'd be ok with SkPixmap being the only version if
SkBitmap wasn't so prevalent in Chrome... but it is. So until then, let's have
both to make things a bit simpler.

[msarett1, 2017/06/12 21:43:11]

Done.

+                     int quality,
+                     std::vector<unsigned char>* output);
 
   // Decodes the JPEG data contained in input of length input_size. The
   // decoded data will be placed in *output with the dimensions in *w and *h