Closed Bug 1504448 Opened 10 months ago Closed 10 months ago
P images only partially draw
47 bytes, text/x-phabricator-request
|Details | Review|
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
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
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 email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1262664295ff Fix buffering problems in WebPDecoder. r=tnikkel
This is getting ridiculous. The large test case isn't rendering for me in the pgo build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ago → 10 months ago
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.