Bug 297393
| Summary: | [GTK][WPE] Stuttering when playing WebP animations | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Miguel Gomez <magomez> |
| Component: | WebKitGTK | Assignee: | Miguel Gomez <magomez> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bugs-noreply |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Miguel Gomez
On embedded devices, some heavy WebP animations will stutter at some points of the playback. This can be reproduced in https://ytlr-cert.appspot.com/2021/manual/webp_animated.html, with the marbles or the skeletons animations (it won't be visible on the desktop because it's too powerful).
The problem comes from the way WEBPImageDecoder::clearFrameBufferCache() clears the stored decoded frames. This method will be called every now and then to clear all the decoded frames before some index, and this index is the next frame we will request in the animation. But in most of the cases, to decode a frame we need to have the previous frame decoded as well.
The current code deletes all the decoded frames before the index requested (let's say N). Due to this, when we want to decode frame N, we may need to decode frame N-1 first, but that may need frame N-2, etc, until we may eventually reach frame 0. So we would need to decode all the frames up to frame N before decoding frame N itself, and that's what's causing the suttering.
The way to fix this is by keeping the last complete frame previous to N. That way we can start decoding from that frame up to N. In most of the cases, the last complete frame will be N-1, so we would only need to decode frame N.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Miguel Gomez
Pull request: https://github.com/WebKit/WebKit/pull/49386
EWS
Committed 298831@main (f7d01f974268): <https://commits.webkit.org/298831@main>
Reviewed commits have been landed. Closing PR #49386 and removing active labels.