AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Consider the start_coord in interlaced PNG

Browse Source 
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
This commit is contained in:
scroggo 2016-10-18 09:14:11 -07:00 committed by Commit bot
parent f1e7583826
commit e9ea349ff1
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/codec/SkPngCodec.cpp
View File

@ -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) {