Consider the start_coord in interlaced PNG

crrev.com/2420843003 (DIFFERENT ISSUE) resulted in a slight difference
in Gold for interlaced PNGs. The new images appeared to have slid down
slightly, implying that we sampled pixels higher (earlier) in the
image.

It turns out we were not truly taking get_start_coord into account.
This CL initializes the srcRow to consider get_start_coord, and should
fix the problem/difference.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2424353003

Review-Url: https://codereview.chromium.org/2424353003

1 files changed, 6 insertions, 4 deletions

diff --git a/src/codec/SkPngCodec.cpp b/src/codec/SkPngCodec.cpp
index 7083137d58..50c107172a 100644
--- a/src/codec/SkPngCodec.cpp
+++ b/src/codec/SkPngCodec.cpp
@@ -726,14 +726,16 @@ private:
 
         // FIXME: For resuming interlace, we may swizzle a row that hasn't changed. But it
         // may be too tricky/expensive to handle that correctly.
-        png_bytep srcRow = fInterlaceBuffer.get();
+
+        // Offset srcRow by get_start_coord rows. We do not need to account for fFirstRow,
+        // since the first row in fInterlaceBuffer corresponds to fFirstRow.
+        png_bytep srcRow = SkTAddOffset<png_byte>(fInterlaceBuffer.get(),
+                                                  fPng_rowbytes * get_start_coord(sampleY));
         void* dst = fDst;
-        for (int rowNum = fFirstRow + get_start_coord(sampleY); rowsWrittenToOutput < rowsNeeded;
-                rowNum += sampleY) {
+        for (; rowsWrittenToOutput < rowsNeeded; rowsWrittenToOutput++) {
             this->applyXformRow(dst, srcRow);
             dst = SkTAddOffset<void>(dst, fRowBytes);
             srcRow = SkTAddOffset<png_byte>(srcRow, fPng_rowbytes * sampleY);
-            rowsWrittenToOutput++;
         }
 
         if (fInterlacedComplete) {