Add support for multiple frames in SkCodec

include/codec/SkCodec.h

Index: include/codec/SkCodec.h
diff --git a/include/codec/SkCodec.h b/include/codec/SkCodec.h
index 363347dd72c08f0e05f97433bf9a5da473df05ea..b991ecab3aada96c94afab94ed294430b7bf6e48 100644
--- a/include/codec/SkCodec.h
+++ b/include/codec/SkCodec.h
@@ -18,6 +18,8 @@
 #include "SkTypes.h"
 #include "SkYUVSizeInfo.h"
 
+#include <vector>
+
 class SkColorSpace;
 class SkData;
 class SkPngChunkReader;
@@ -220,6 +222,38 @@ public:
     };
 
     /**
+     *  Additional options that only apply to multiframe images.
+     */
+    struct MultiFrameOptions {
+        MultiFrameOptions()
+            : fIndex(0)
+            , fHasPriorFrame(false)
+        {}
+
+        /**
+         *  The frame to decode.
+         */
+        size_t fIndex;
+
+        /**
+         *  If true, the dst already contains the prior frame.
+         *
+         *  If fIndex needs to be blended with a prior frame (as reported by
+         *  getRequiredFrame(fIndex)), the client can set this to either
+         *  true or false:
+         *
+         *  true means that the prior frame is already in the dst, and this
+         *  codec only needs to decode fIndex and blend it with the dst.
+         *  Options.fZeroInitialized is ignored in this case.
+         *
+         *  false means that the dst does not contain the prior frame, so this
+         *  codec needs to first decode the prior frame (which in turn may need
+         *  to decode its prior frame).
+         */
+        bool   fHasPriorFrame;
+    };
+
+    /**
      *  Whether or not the memory passed to getPixels is zero initialized.
      */
     enum ZeroInitialized {
@@ -243,10 +277,11 @@ public:
     struct Options {
         Options()
             : fZeroInitialized(kNo_ZeroInitialized)
-            , fSubset(NULL)
+            , fSubset(nullptr)
+            , fFrameOptions(nullptr)
         {}
 
-        ZeroInitialized fZeroInitialized;
+        ZeroInitialized     fZeroInitialized;
         /**
          *  If not NULL, represents a subset of the original image to decode.
          *  Must be within the bounds returned by getInfo().
@@ -264,7 +299,14 @@ public:
          *  subset left and subset width to decode partial scanlines on calls
          *  to getScanlines().
          */
-        SkIRect*        fSubset;
+        SkIRect*            fSubset;
+
+        /**
+         *  Options that are only relevant for multi-frame images.
+         *
+         *  Unowned pointer.
+         */
+        MultiFrameOptions*  fFrameOptions;
     };
 
     /**
@@ -566,6 +608,40 @@ public:
      */
     int outputScanline(int inputScanline) const;
 
+    // The required frame for an independent frame is marked as
+    // kIndependentFrame.
+    static constexpr size_t kIndependentFrame = static_cast<size_t>(-1);
+
+    /**
+     *  Information about individual frames in a multi-framed image.
+     */
+    struct FrameInfo {

[scroggo, 2016/09/26 15:51:43]

I also considered "FrameMetaData". Any preference for one or the other?

[msarett, 2016/09/26 17:30:53]

I prefer FrameInfo, but don't feel strongly.

+        /**
+         *  The frame that this frame needs to be blended with, or
+         *  kIndependentFrame.
+         */
+        size_t fRequiredFrame;
+
+        /**
+         *  Number of 1/100 seconds to show this frame.

[msarett, 2016/09/26 17:30:53]

I'm guessing "1/100 seconds" is what Chrome does?  Is there is a particular
reason?  Maybe because this is as precise as we can be?

Just asking because I imagine milliseconds is more intuitive for a client than
"centiseconds".

[scroggo, 2016/09/26 17:43:11]

D'oh - good catch. I just used 1/100 seconds because that's how GIF stores it.
But Chrome multiplies that by 10 and stores the milliseconds. I've fixed this.

+         */
+        size_t fDuration;
+    };
+
+    /**
+     *  Return info about the frames in the image.
+     *
+     *  May require reading through the stream to determine the number of
+     *  frames.
+     *
+     *  As such, future decoding calls may require a rewind.
+     *
+     *  For single-frame images, this will return an empty vector.
+     */
+    std::vector<FrameInfo> getFrameInfo() {
+        return this->onGetFrameInfo();
+    }
+
 protected:
     /**
      *  Takes ownership of SkStream*
@@ -706,6 +782,11 @@ protected:
 
     virtual int onOutputScanline(int inputScanline) const;
 
+    virtual std::vector<FrameInfo> onGetFrameInfo() {
+        // empty vector - this is not animated.
+        return {};
+    }
+
     /**
      *  Used for testing with qcms.
      *  FIXME: Remove this when we are done comparing with qcms.