Add a SkPixelSerializer SkImage encode variant

include/core/SkImage.h

Index: include/core/SkImage.h
diff --git a/include/core/SkImage.h b/include/core/SkImage.h
index 5b9e2031758f8ebc317041289a0603f8113d1ece..763ccc6882815b941cdf0996c3d83e8fbcb5b16f 100644
--- a/include/core/SkImage.h
+++ b/include/core/SkImage.h
@@ -21,6 +21,7 @@ class SkColorTable;
 class SkImageGenerator;
 class SkPaint;
 class SkPicture;
+class SkPixelSerializer;
 class SkString;
 class SkSurface;
 class SkSurfaceProps;
@@ -223,9 +224,16 @@ public:
      */
     SkData* encode(SkImageEncoder::Type, int quality) const;
 
-    SkData* encode() const {
-        return this->encode(SkImageEncoder::kPNG_Type, 100);
-    }
+    /**
+     *  Encode the image's pixels using an optional SkPixelSerializer, and return the result
+     *  as a caller-managed SkData.
+     *
+     *  If the serializer is NULL, a default PNG encoder (with quality == 100) will be used.

[reed1, 2015/09/03 02:36:13]

How about this as a way to organize this wackiness:

- This attempts to return the image as an encoded (compressed) data.
- If the image already has itself in that form (i.e. refEncoded() returns a
data), we return that.
- Else we try to encode the image into PNG.

However, if the caller passes a pixel-serializer, then it can change this
behavior:
- if the image returns data from refEncoded(), that is passed to the serializer,
which can reject it (e.g. that format may not be supported by the intended
recipient).
- if we need to encode/compress the raw pixels, the serializer may perform that,
and return the data in any format it chooses.

Actually I think mine is also confusing. Anyway, I do want us to be explicit
about the contract (e.g. order of what we check when), but wording it is clearly
hard.

If there is a serializer, we completely defer to it. If it fails, we will fail
(return null).

If there is no 

[f(malita), 2015/09/03 14:10:27]

(this looks truncated, did you have more text which didn't post?)

Yeah, describing the behavior seems tricky.  Always a bad sign :)

How about we focus on the serializer-present flow, and then describe the
default-serializer (instead of a separate serializer-missing flow)?

Updated, but don't feel strongly and at this point I'll just past whatever you
prefer.

+     *
+     *  This method may return exising encoded data (from refEncoded) if it passes the
+     *  serializer's useEncodedData() test, or the serializer itself is NULL.
+     */
+    SkData* encode(SkPixelSerializer* = nullptr) const;
 
     /**
      *  If the image already has its contents in encoded form (e.g. PNG or JPEG), return a ref