Repository navigation
[1/2] fix: keep a frame's embedded images when Safari draws an html5 clip - #279
Merged
Merged
Conversation
This was referenced Oct 30, 2026
dazzatronus
force-pushed
the
derk/html5-safari-embedded-images
branch
from
October 30, 2026 12:36
baaecce to
36fc6f0
Compare
github-actions Bot
pushed a commit
that referenced
this pull request
Oct 30, 2026
## [2.30.1](v2.30.0...v2.30.1) (2026-10-30) ### Bug Fixes * draw clip filters in the preview as the render applies them ([#265](#265)) ([ac02f9b](ac02f9b)) * draw html5 frames on a software canvas so Firefox keeps their gradients ([#280](#280)) ([d508db8](d508db8)) * **export:** draw export frames into one stencil target so Firefox keeps masked content ([#278](#278)) ([f431c6b](f431c6b)) * **export:** tag browser exports as limited range so Safari's whites stay white ([#277](#277)) ([c6150eb](c6150eb)) * keep a frame's embedded images when Safari draws an html5 clip ([#279](#279)) ([5154007](5154007)) * keep baking html5 clips while their tab is in the background ([#281](#281)) ([e1fa158](e1fa158))
|
🎉 This PR is included in version 2.30.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This was referenced Oct 31, 2026
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.
Safari drops large images from html5 frames. A clip's frames are drawn by loading the page as an SVG image, and WebKit lays that page out as offscreen. So a bitmap over about 500 KB once decoded (a 960×540 photo is about 2 MB) decodes asynchronously, and a draw that comes before the decode lands leaves it out.
img.decode()doesn't wait for that decode and no event marks it. Redrawing the same SVG 400 ms apart showed the image appearing and disappearing, so any timed wait is a race.In WebKit, each frame's SVG now starts with one hidden
<img decoding="sync">for each embedded base64 bitmap, which decodes it at full size within the draw. They're hidden withfilter:opacity(0), because WebKit skips paintingopacity:0elements. The bake cache key gains a drawing version, so frames already cached without their images are redrawn.WebKit is detected by
navigator.vendor, which every iOS browser shares with Safari. Chrome doesn't need the extra decodes, and they cost it about 23% more bake time on the edit below.Verify:
npm run verify:ci. Then, in Safari, preview an html5 clip whose CSS has a largebackground-imagedata URI: every frame shows it. On one such edit (374 frames, full bake) the frames below 0.95 SSIM against a cloud render fell from 121 to 2. Chrome's export of that edit is identical tomain's.Risk: in WebKit each frame's SVG carries its embedded images twice (231 KB → 386 KB here), and the Safari bake took about 14% longer. If WebKit ever stops painting
filter:opacity(0)elements, images go missing as they do today.Merge bottom-up: #280 targets #279's branch, and moves to
mainonce #279 lands.