Repository navigation
Animated GIF preview in Firefox (4.1.1.0) - #56
Merged
Merged
Conversation
Firefox keeps handing drawImage() the same frame of an animated GIF <img>, so the editor preview stood still although the repaint loop ran. Where WebCodecs' ImageDecoder exists, the GIF's frames are now decoded one at a time and painted from a per-image canvas at the GIF's own frame delays (<= 10 ms -> 100 ms), driven by the existing single gifTick loop and its 15 fps cap. Each VideoFrame is closed right after drawing; a frame that arrives for a replaced background or a stopped loop is dropped and the index kept, so returning to the page resumes. The decoder is closed when its bitmap is replaced, cleared, loses the pick race or fails to load. Without ImageDecoder, or if it fails, the old <img> path is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review round 1 for 4.1.1.0: - Decoded playback keeps a schedule: nextAt += delay (not now + delay), frames whose time is over are skipped (decode() returns composited frames), per-frame delays are remembered as numbers, and the clock restarts on (re)start or when more than a loop behind, so a return to the page does not fast-forward. Fast GIFs now play in real time under the 15 fps render cap (also in Chrome, where the <img> path did). - frameCount is read after Promise.all([tracks.ready, completed]) and re-read in the stepper, since Firefox reports it late. - Simplified the draw-source expression; console.debug on a real decode failure before falling back to the <img>. - CHANGELOG wording: real-time speed, redrawn up to ~15 fps. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release 4.1.1.0: an animated GIF background now also moves in the live preview in Firefox.
Cause
A probe on the user's Firefox 153 with 4.1.0.0 showed that the GIF was recognised and the repaint loop was running (119 calls in 2 s). Even so,
drawImageof the animated<img>kept returning the same frame. Chrome draws an animated image's current frame; Firefox doesn't for this hidden image. Applied covers were never affected.Fix
ImageDecoder(Firefox ≥ 133, Chrome/Edge ≥ 94) and draws the current frame.VideoFrameis closed.decoder.completed, because Firefox may report it late.nextAt += delay, with per-frame delays. Late frames are skipped, while redraws stay capped at about 15 per second. The clock resyncs on resume, so returning to the page doesn't fast-forward.ImageDecoder(Safari), or if decoding fails, the editor falls back to the previous<img>behaviour; a failure is logged withconsole.debug.CHANGELOG
## 4.1.1.0and README are updated.Testing
completed) that was then re-reviewed.Live check (not yet done in a real Firefox)
🤖 Generated with Claude Code