Jerky Preview experience

[yyovil]

Describe the bug

When I try to preview compositions full of images, the experience is very terrible. I have to render the composition separately just to preview it without those jerks and that breaks the dev workflow.

jerky-hyperframes-preview.mp4

Link to reproduction

https://github.com/yyovil/creatives.git

Steps to reproduce

1. Clone the repo above
2. Run the preview using pnpx hyperframes preview
3. Wait (~3s) until the composition containing lots of images starts playing
4. You should experience the same jerk as in the video uploaded in the description.

Expected behavior

The preview should be same as the render experience

Actual behavior

I experienced the jerky preview when the composition is full of images.

Environment

✓ Version          0.4.4 (latest)
✓ Node.js          v22.22.1 (darwin arm64)
✓ FFmpeg           ffmpeg version 8.0 Copyright (c) 2000-2025 the FFmpeg developers
✓ Chrome           system: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Additional context

I'm using a macbook air with M4 chip, 10 CPU and 10 GPU cores with 16GBs of RAM and 256GBs of Storage.

output of pnpx hyperframes doctor

[jrusso1020]

Thanks for the clean repro, it made this easy to measure.

I pulled down the repo and did some isolation testing, and the bottleneck here isn't image decode or runtime overhead. It's compositor-side paint cost from the stacked backdrop-filter: blur(...) layers.

What I measured

Mounted image-carousel.html standalone, animated the carousel translate with requestAnimationFrame, and measured frame intervals over 3 seconds at 1920x1080:

Variant	Avg frame	Jank % (>33 ms)
Baseline (overlay opacity: 0, as authored)	16.8 ms	1%
No backdrop-filter overlay	16.8 ms	1%
No overlay AND no images	16.7 ms	1%
Only images, no dimmed-strip, no overlay	16.6 ms	0%
Backdrop-filter overlay made visible (like scene 8/11)	194.7 ms	81%

With all 23 images visible and the dimmed-strip on screen, the composition runs a steady 60 FPS. It's only during scenes where .progressive-blur-overlay gets opacity 1 (scenes 8 and 11 in your CSS) that frame times jump to ~230 ms. That's where the jerks are coming from.

For reference, I also measured raw img.decode() on all 23 assets sequentially: about 0.1 ms total. Images are not the issue.

Why render looks fine but preview doesn't

Render captures frames one at a time then stitches them into a video, so slow frames just make the render take longer, no visible jank. Preview does the same work in real time, so any frame over 33 ms shows up as stutter.

Quickest workaround (if you want to ship now)

Your current workflow of rendering first, then watching the mp4, is honestly fine as a temporary fix. Nothing wrong with it.

Actual fixes, easiest first

1. Drop the two biggest blur radii. .pb-l-8 and .pb-r-8 are blur(128px). .pb-l-7 and .pb-r-7 are blur(64px). Those four layers do the bulk of the GPU work. Try commenting them out first and see if scenes 8/11 start playing smoothly. You'll probably lose very little visually because the smaller-radius layers already cover that end of the gradient.

2. Cut the blur stack down. 8 stacked backdrop-filter layers per side is a lot. Try 3 (say 4px, 32px, 128px) with adjusted masks. Most progressive-blur effects people build look the same with 2-3 well-tuned layers.

3. Downsize the source images. They're 7413x4913 but display in 384x1080 cards. Each decoded bitmap is ~140 MB, total ~2 GB across all 23. Chrome has to upload these as GPU textures and resample them every frame the backdrop-filter fires. Resize them to ~2K wide (still sharper than the card) and you'll cut texture upload and compositor cost a lot. This alone would likely help scenes 8/11 noticeably.

4. Pre-render the blur. Bake the progressive-blur gradient into a static PNG and overlay it with a normal <img>. Once precomputed, it composites for free. Takes more work but completely sidesteps the issue.

On PR #325

There's an in-flight PR that adds eager img.decode() to the runtime. It's reasonable as a general hardening change, but it won't fix what you're seeing here. I've posted the measurement details over there.

Happy to share the scripts if you want to reproduce. And if you try any of the above, curious to hear whether it moves the needle.

[yyovil]

woah resizing them helped and the preview is on par with the standard rendered quality. Such a QoL improvement.

Hey I've vouched for yall in a x.com post.