Closed Bug 1504448 Opened 10 months ago Closed 10 months ago

WebP images only partially draw

Categories

(Core :: ImageLib, defect, P3)

65 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: adrianm2, Assigned: aosmond)

Details

Attachments

(1 file)

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.
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
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.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → ImageLib
Ever confirmed: true
Flags: needinfo?(aosmond)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Looks like the decoder is either stopping or stuck in a loop.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Flags: needinfo?(aosmond)
Priority: -- → P3
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.
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.
Pushed by aosmond@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1262664295ff
Fix buffering problems in WebPDecoder. r=tnikkel
https://hg.mozilla.org/mozilla-central/rev/1262664295ff
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
This is getting ridiculous. The large test case isn't rendering for me in the pgo build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: needinfo?(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).
For me the patch works fine.
Now that the new build pushed, it works. Whew.
Status: REOPENED → RESOLVED
Closed: 10 months ago10 months ago
Flags: needinfo?(aosmond)
Resolution: --- → FIXED
Great!!
Thx a lot for implementing webp support :)
It's working flawlessly for me now.
You need to log in before you can comment on or make changes to this bug.