Compare image-webp and webp-sys

[woelper]

Do an investigation about % images supported for a given test corpus.

[woelper]

Closing this in favor of webp-animation, which is used now.

[Shnatsel]

The support for animated WebP in image has improved a lot. There is still an outstanding issue where the background color is treated differently from other libraries, but that seems like a fairly simple fix.

Could you re-run the tests with image v0.25.4 and post the failures to the image issue tracker, or simply share your test corpus? We'd very much like to identify and fix the remaining issues, if there are any!

[woelper]

You are reading my mind, as this was exactly what I did last night after I updated image.
I started with setting up criterion to spot any differences in performance when I test out other methods. When I used the native image method to load animations, I remembered why I decided to use webp-animation: While it works perfectly with just image, I have to wait for the whole animation to load with decoder.into_frames(). webp-animation lets me individually step through frames and display them as they are decoded, where with image I get a huge delay. With larger multi-frame images this is very noticeable and adds seconds of delay when opening.
It did however open all the images I tested.

[Shnatsel]

Thank you!

Could you share the exact code used for the comparison? Looking at the code, the decoder in image should be able to decode the frames lazily.

[woelper]

I think I was wrong in assuming that into_frames() was the slow part. From looking at it more, the into_frames is very fast, but decoding the individual frames is slower. With image, it takes roughly 1.5 secs with opt-level=2 and 430 ms with webp-animation decoding all image frames.

The code is very simple:

       let frames = image::AnimationDecoder::into_frames(decoder);
                
                for frame in frames {
                    if let Ok(f) = frame {
                        let (n, d) = f.delay().numer_denom_ms();
                        let delay = n / d;
                        let frame =
                        Frame::new(f.buffer().clone(), delay as u16, FrameSource::Animation);
                        _ = sender.send(frame);
                    }
                }

sample.zip

[Shnatsel]

Thank you, I'll investigate.

Also, why would you use opt-level=2? The default for cargo build --release is opt-level=3.

If you are concerned about debug mode build times, just add this to your Cargo.toml:

# Most of the time is spent in `image` and its dependencies,
# so build it with optimizations in debug mode to get good performance
# while simultaneously having `cargo build` complete quickly for short iteration times
[profile.dev.package.image]
opt-level = 3

[Shnatsel]

I can reproduce the 4x difference in speed compared to webp-animation with opt-level=3. I've filed an issue and did some analysis on it: image-rs/image-webp#119