GitLab

The gif-animated-partial-load.html web test examines the intermediate
rendering of loading a GIF image over a simulated slow network
connection - an incomplete image.

The GIF spec (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) describes
how to decode a complete GIF file, but does not mention intermediate
on-screen state. Different decoders have leeway to present different
partial decodings.

Specifically, Chromium's old decoder only output complete rows of pixels
and consumed only complete blocks of data. Chromium's new decoder can
output partial rows and consume partial blocks. (A GIF image's
compressed pixel data is framed into a sequence of blocks. Each block
has a length byte, then up to 255 bytes of payload.)

For interlaced GIFs, the old and new decoders also take different
approaches as to how to expand 'tall' rows: whether the explicit row is
the center or the top of the strip of implied rows.

To repeat, different (spec-compliant) GIF decoders can produce different
partial decodings. The Blink web test does a pixel-exact comparison to a
golden screenshot, so this commit also updates that screenshot.

https://bugs.chromium.org/p/chromium/issues/detail?id=1014044#c3 shows
the old and new screenshots.

This commit isn't about performance per se, it is about tracking
upstream Skia. Nonetheless, here are some before-vs-after total times
for Chromium's "image_decode_bench -i 10" program for x86_64, on a
selection of GIF images that noel@chromium.org collects:

old_time  new_time  ratio file_name  file_size
0.000143  0.000391  0.37  bar.gif          265
0.000282  0.000401  0.70  radient.gif     1034
0.001328  0.001290  1.03  mondrian.gif    3792
0.002619  0.001893  1.38  rain.gif       10272
0.009508  0.005642  1.69  flag.gif       41738
0.021562  0.013780  1.56  warp.gif      106420
0.390664  0.301473  1.30  hex.gif      1072114

A ratio higher is better: more than 1.00 means that the new GIF decoder
is faster than the old one. The ratios are consistent with the
hypothesis that the new decoder has a higher fixed cost but lower
per-pixel cost (cost in terms of time taken). Overall, it is arguably a
net improvement in absolute time taken. The same relative difference
(ratio) means larger absolute differences for larger images.

Bug: 1014044
Change-Id: I20e2d6281945b8219778d049c3d09a52f456aed0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898151Reviewed-by: Leon Scroggins <scroggo@chromium.org>
Commit-Queue: Nigel Tao <nigeltao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713336}