Issue 362 in webp: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)

20 views
Skip to first unread message

lizhuoli… via monorail

unread,
Oct 18, 2017, 12:03:58 PM10/18/17
to webp-d...@webmproject.org
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 362 by lizhuoli...@gmail.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362

What steps will reproduce the problem?
1. Use x86 Architecture device (I test on iPhone simulator and macOS)
2. Use multiple WebPIDecoder to do incrementally decoding for WebP images in different threads
3. Use WebPIDecGetRGB to grab decoded rgba bitmap and draw CGImage

What is the expected output? What do you see instead?

Excepted: Each WebPIDecoder in different thread can get the valid rgba and draw correct CGImage without affecting each other.

What I See: Suppose two WebPIDecoders A and B. A finish incrementally decoding and then B start incrementally decoding. A's rgba is correct and draw imageA. But B's rgba is not correct and contains A's part. The imageB will looks like two image bitmap merged. The top part of imageB is current decoded partial imageB but the bottom part is the partial imageA.

Please see the attach image file for this strange image bitmap. :)

What version of the product are you using? On what operating system?
Version: libwebp: 0.6.0
System: I test macOS(x86), iPhone simulator(x86) and it contains this bug. But for iPhone device(ARM & ARM64) this bug can not be reproduced.

Please provide any additional information below.

The decoding code is from open-source iOS/macOS project SDWebImage: https://github.com/rs/SDWebImage/blob/a0879fc049453c9028e2e1a9755cd9028aecf5f5/SDWebImage/SDWebImageWebPCoder.m#L195

We use that `last_y` to create partial height CGImage to avoid this bug. But I think this should be fixed in other better way since this works great on ARM architecture.

Attachments:
2017-10-18-15-56-37.png 1014 KB

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

pascal.m… via monorail

unread,
Oct 18, 2017, 1:14:57 PM10/18/17
to webp-d...@webmproject.org

Comment #1 on issue 362 by pascal.m...@gmail.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c1

You should only refresh the output buffer between row 0 and last_y.

What i think is happening here is that the output buffer from decoder A is released when decoder A is destroyed, but immediately re-used for decoder B (when malloc() is called), without re-initialization.

What you're seeing is the remains of the previous decoding job from decoder A.

Can you try to put some zeroes in the output buffer just after creating a WebPIDecoder?
This should make the partial image disappear if that's the correct symptom.

The right think to do, of course, is to only blit to screen the area between row=0 and last_y.

lizhuoli… via monorail

unread,
Oct 21, 2017, 11:08:17 AM10/21/17
to webp-d...@webmproject.org

Comment #2 on issue 362 by lizhuoli...@gmail.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c2

Thanks for you reply.

In fact, this issue not need to call WebIDecoder simultaneously. I try the code provided there. Set a breakpoint and see. After one decoder finished and it called `WebPIDelete(_idec);`, Then I open another image to trigger decoder. But I also found that return rgba contains the previous image bitmap. Firstly I think maybe the API I used is `WebPINewRGB` and this is because it use `is_external_memory`.

But I try all the 3 API(`WebPINewRGB`, `WebPINewDecoder` and `WebPIDecode`). Even I set the output buffer to my own class object's property and call `WebPFreeDecBuffer` manually. This strange partial bitmap is still here. So I guess there maybe some memory manage issue with libwebp. But I'm not really familiar with C code and the implementation for image decoding lib. So I decide to tick this issue.

And thanks for your advice about that `You should only refresh the output buffer between row 0 and last_y.`. I think I should always obey this. But in fact, this issue can only happen on x86 architecture but not ARM architecutre. So I don't think this is a designed behavior :) So please check this issue if you have time. Thanks !

lizhuoli… via monorail

unread,
Oct 21, 2017, 11:12:23 AM10/21/17
to webp-d...@webmproject.org

Comment #3 on issue 362 by lizhuoli...@gmail.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c3

Thanks for your reply.

In fact, this issue do not need to call WebIDecoder simultaneously or in a multi-thread environment. I try the code provided above. Set a breakpoint and check. After one decoder finished, it actually called `WebPIDelete(_idec);`, Then I open another image to trigger decoder. But I also found that return rgba contains the previous image bitmap. Firstly I think maybe the API I used is `WebPINewRGB` and its not set `is_external_memory`. So there are maybe some inner memory manage process not happened immediately.

But then, I try all the 3 APIs(`WebPINewRGB`, `WebPINewDecoder` and `WebPIDecode`). Even I set the output buffer pointer to my own class object's property and call `WebPFreeDecBuffer` manually. This strange partial bitmap is still here. So I guess there maybe some memory manage issue with libwebp. But I'm not really familiar with C code and the implementation for image decoding lib. So I decide to tick this issue.

And thanks for your advice about that `You should only refresh the output buffer between row 0 and last_y.`. I think I should always obey this. But in fact, this issue can only happen on x86 architecture but not ARM architecutre. So I don't think this is a designed behavior :) So please check this issue if you have time, Thanks ! :)

jz… via monorail

unread,
Nov 16, 2017, 1:41:32 AM11/16/17
to webp-d...@webmproject.org

Comment #4 on issue 362 by jz...@google.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c4


> Can you try to put some zeroes in the output buffer just after creating a WebPIDecoder?

Were you able to try this suggestion?

And to rule out a usage issue with the incremental decoder, maybe try WebPDecodeRGBA or a similar variant [1].

[1] https://developers.google.com/speed/webp/docs/api#simple_decoding_api

jz… via monorail

unread,
Mar 31, 2018, 2:32:10 AM3/31/18
to webp-d...@webmproject.org
Updates:
Labels: Needs-Feedback

Comment #5 on issue 362 by jz...@google.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c5

Any update on this? Without more detail we'll close this bug soon.

jz… via monorail

unread,
Sep 25, 2018, 8:22:03 PM9/25/18
to webp-d...@webmproject.org
Updates:
Status: Invalid

Comment #6 on issue 362 by jz...@google.com: WebPIDecoder does not get correct rgba bitmap on multi-threads env on x86 architecture(but works great on ARM)
https://bugs.chromium.org/p/webp/issues/detail?id=362#c6

Closing this one for now. If you're still experience the issue and have an update based on comment #1 please feel free to reopen.
Reply all
Reply to author
Forward
0 new messages