Closed Shnatsel closed 39 minutes ago
Are you sure? Looking at the code, it seems that next_frame
is called lazily within webp::FramesInner::next
each time a new frame is requested. Though if you call collect
on the iterator it'll of course decode all the frames.
image-webp
does scan the chunk headers for each frame of the animation when creating the decoder (to determine the animation runtime and determine whether the image uses lossy compression), but I'd expect that to be comparatively cheap.
That was an incorrect assumption, the performance bottleneck is elsewhere: https://github.com/woelper/oculante/issues/252#issuecomment-2430073021
I'll investigate and open an issue with a profile.
As of v0.25.4,
WebPDecoder::into_frames()
decodes the entire animation up front, as opposed letting the user read frames one by one.This is a blocker for Oculante to migrate away from
libwebp-sys
+webp-animation
toimage
's memory-safe WebP animation decoder: https://github.com/woelper/oculante/issues/252#issuecomment-2428315428This will also be an issue for
wondermagick
which will need to support decoding a set of specific frames, and always decoding all of the frames will be slow.