1504448 - WebP images only partially draw

Status: RESOLVED FIXED

(Core :: ImageLib, defect, P3)

Description

[adrian]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

1. enable experimental webp support

2. load https://developers.google.com/speed/webp/gallery1, and click on a webp image.



Actual results:


Sometimes only the top of the image is shown.  When visiting the image info page(right click-> view image info) the full image is shown.

Happens on reddit too.


Expected results:

Image should fully draw.

Comment 1

[adrian]

I tired again with a new profile (image.webp.enabled only profile change), and webp drawing is still only partial.


I can't make these changes, but I believe that this bug should be:
Product:Core 
Component:ImageLib

Comment 2

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
20181103100108

The first three images rendered fine, but the fourth was mostly white. It doesn't seem specific to that file, since it's also reproducible going back to one of the other images and pressing Ctrl+Shift+R, waiting for it to load, and repeating if necessary.

Comment 3

[Andrew Osmond [:aosmond]]

Looks like the decoder is either stopping or stuck in a loop.

Comment 4

[Andrew Osmond [:aosmond]]

I made a few rather large mistakes here and am learning about the blind spots in our gtest coverage (in general). I really regret not using StreamingLexer now as well, as it would have caught one class of problems.

Comment 5

[Andrew Osmond [:aosmond]]

Attachment: Bug 1504448 - Fix buffering problems in WebPDecoder.

There were two unrelated buffering problems in nsWebPDecoder. The first
was with the decoder contract. We are expected to loop until the
iterator is unable to provide more data, and wait for the SourceBuffer
to reschedule us, where as nsWebPDecoder::DoDecode only did one pass.
Thus when something yielded wanting more data, we would just wait
forever.

The second was the integration with the libwebp API. We are expected to
retry when we receive SUSPENDED from the decoder, as it decided to yield
pixels instead of continuing to decode as many as possible.

The tests did not cover the first problem because multi chunk decoder
tests do not use SourceBuffer scheduling. This is an oversight. They now
will write a chunk of data, let the SourceBuffer reschedule the decoder,
and repeat until all of the data has been written.

The tests did not cover the second problem because all of the reference
WebP images are too small. This patch adds a new test with a large WebP
image (converted from a Mozilla all hands photo of lanyards). This
should actually trigger the SUSPEND behaviour of libwebp.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1262664295ff
Fix buffering problems in WebPDecoder. r=tnikkel

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/1262664295ff

Comment 8

[Andrew Osmond [:aosmond]]

This is getting ridiculous. The large test case isn't rendering for me in the pgo build.

Comment 9

[Andrew Osmond [:aosmond]]

This may have been premature. The nightly was produced with my patch, but it won't push to me via an update (maybe it was pulled due to a bug).

Comment 10

[Marco Sousa]

For me the patch works fine.

Comment 11

[Andrew Osmond [:aosmond]]

Now that the new build pushed, it works. Whew.

Comment 12

[Djfe]

Great!!
Thx a lot for implementing webp support :)
It's working flawlessly for me now.