Make SkPngCodec decode progressively.

src/codec/SkGifCodec.cpp

Index: src/codec/SkGifCodec.cpp
diff --git a/src/codec/SkGifCodec.cpp b/src/codec/SkGifCodec.cpp
index 75e9d63fa72ad3e6099341db39eb7de376d0b470..dcc25b8dfd83986724deec6ae9d86b141a46db24 100644
--- a/src/codec/SkGifCodec.cpp
+++ b/src/codec/SkGifCodec.cpp
@@ -520,7 +520,7 @@ uint32_t SkGifCodec::onGetFillValue(SkColorType colorType) const {
 
 SkCodec::Result SkGifCodec::onStartScanlineDecode(const SkImageInfo& dstInfo,
         const SkCodec::Options& opts, SkPMColor inputColorPtr[], int* inputColorCount) {
-    return this->prepareToDecode(dstInfo, inputColorPtr, inputColorCount, this->options());
+    return this->prepareToDecode(dstInfo, inputColorPtr, inputColorCount, opts);

[scroggo, 2016/05/26 20:25:10]

https://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX...
caught an interesting bug - we should've been using "opts", which was passed
into this function, but instead we were using this->options(), which would have
gotten updated to "opts" after this call returned. (Maybe the order is confusing
and we should fix it and/or safeguard it? I don't see any other callers of
options() that appear to be making this mistake though.)

This bug has been around a while*, and definitely went into N. The good news is,
we don't support fSubset in GIF. The only other Option is zero initialized.
Fortunately, Android doesn't reuse the same SkCodec (except for BRD, which
doesn't support GIF), so it will always reuse the default options, and the
default options include kNo_ZeroInitialized. This means that for GIF, we won't
take advantage of zero-initialized memory. But that's not so terrible.

* Since scanline decoding was added to GIF in crrev.com/1305123002

[msarett, 2016/05/26 20:29:12]

That's too bad.  Thanks for pointing this out.

 }
 
 void SkGifCodec::handleScanlineFrame(int count, int* rowsBeforeFrame, int* rowsInFrame) {