Bug 217897 – [iOS 14] Animated WebP with transparency doesn't render properly

• Component: Images
• Status: RESOLVED MOVED

[Alan Davalos]

Created attachment 411728 [details]
Video showing how the WebP display on other browsers (left) vs how it displays on iOS 14 (right)

Rendering for animated WebP with transparency doesn't seem to be working properly on iOS 14.

It doesn't seem to happen to every single image, WebP with no transparency and one example encoded lossless seem to work fine.

But both a sample I found in a stackoverflow question and other one my team prepared seem to show flickering in the background and bits of other frames.

This bug happens both in iOS emulators and actual devices.

I've tested this on other major browser vendors (Chromium, Gecko) and they both seem to work as expected (look at the left side of the attached video)


References: 
- A minimal reproduction I prepared; the video attached was recorded using it: https://animated-webp.glitch.me/
- The stackoverflow question: https://stackoverflow.com/questions/64259387/ios-14-webp-animation-flahes-with-a-white-background-in-safari-and-chrome

[Smoley]

Thanks for filing, I can reproduce this on iOS 14.0 with the provided link.

[Radar WebKit Bug Importer]

<rdar://problem/70582441>

[Alan Davalos]

Thanks for your response, I've got some additional information that might be helpful:

We've done some tests on iOS 14.1 and the rendering for animated Webp seems to have improved quite a bit in that version.

For example, from the images on the reproduction I made, the first two had problems in iOS 14 and now in 14.1 the first one renders properly and the second one seems to still have some problems but at least those regarding to the background seem to have been fixed.

However, I've noticed that some larger animated WebP (over 1MB in size) seem to have a different problem now.

The problem with this kind of images is that the images seem to render in a "slow motion" of sorts.

Judging from the effect, I would guess that the processing for the animation is getting stuck at some point.

As a reference, an APNG image created using the same keyframes would render properly.

Unfortunately, I can't provide a demo for this right now as I can't make the images public but I can try preparing some in case that helps.

Also, if you think this other problem should be registered as a different bug, I can file a new bug so let me know if that would be better.

[Nick Doyle]

Created attachment 414844 [details]
Working GIF

[Nick Doyle]

Created attachment 414845 [details]
Broken WebP

[Nick Doyle]

I've attached two images that demonstrate the problem. It looks like blending method or disposal method or both are not being respected or properly interpreted.

Both images work in Chrome bet the WebP image is broken in Safari.

Created attachment 431786 [details]
Incorrect dispose to background handling

Comment on attachment 431786 [details]
Incorrect dispose to background handling

This is a simpler example of incorrect dispose to background handling. This should clear to the background in the final frame but a leftover couple of columns from frame 2 remain. Frame 3 completely covers frame 2 so it should not need to be disposed of separately. The progression of the image should be red->blue->green->blank (background color may vary based on the application, the default is white).

$ webpmux -info repro.webp 
Canvas size: 216 x 69
Features present: animation transparency
Background color : 0xFFFFFFFF  Loop Count : 1
Number of frames: 4
No.: width height alpha x_offset y_offset duration   dispose blend image_size  compression
  1:   181    41    no       32       28     1000 background    no         42    lossless
  2:   180    41    no       34       28     1000       none    no         42    lossless
  3:   182    41    no       34       28     1000 background    no         42    lossless
  4:     1     1   yes        0        0     1000       none   yes         34    lossless

[Brent Fulgham]

The fix for this issue needs to be made outside of the WebKit source code, therefore marking this as "RESOLVED | MOVED".

[Said Abou-Hallawa]

rdar://107427578

This is new radar tracks other cases which are still failing in Safari 16.4 on macOS Ventura 13.3.