Closed
Bug 1504448
Opened 2 years ago
Closed 2 years ago
WebP images only partially draw
Categories
(Core :: ImageLib, defect, P3)
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
Comment 2•2 years ago
|
||
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
Assignee | ||
Comment 3•2 years ago
|
||
Looks like the decoder is either stopping or stuck in a loop.
Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Flags: needinfo?(aosmond)
Priority: -- → P3
Assignee | ||
Comment 4•2 years ago
|
||
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.
Assignee | ||
Comment 5•2 years ago
|
||
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
Comment 7•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1262664295ff
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Assignee | ||
Comment 8•2 years ago
|
||
This is getting ridiculous. The large test case isn't rendering for me in the pgo build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•2 years ago
|
Flags: needinfo?(aosmond)
Assignee | ||
Comment 9•2 years ago
|
||
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•2 years ago
|
||
For me the patch works fine.
Assignee | ||
Comment 11•2 years ago
|
||
Now that the new build pushed, it works. Whew.
Status: REOPENED → RESOLVED
Closed: 2 years ago → 2 years ago
Flags: needinfo?(aosmond)
Resolution: --- → FIXED
Comment 12•2 years ago
|
||
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.
Description
•