Scroll Image Sequence — Free GSAP Canvas Scrub Snippet

The scroll image sequence is the technique behind Apple's AirPods and MacBook pages: an animation rendered as individual frames, drawn to a <canvas>, with the scrollbar acting as the playhead. Scroll down and the sequence plays forward frame by frame; scroll up and it runs in reverse. This snippet builds the full pipeline — frame storage, a numeric playhead, and a pinned, scrubbed ScrollTrigger — with GSAP loaded from a CDN.

Frames are pre-rendered once, not drawn per scroll event

The demo generates 80 frames procedurally (an orbiting particle ring with a growing core) and paints each one into its own offscreen document.createElement('canvas') at build time. That mirrors how a production sequence works with exported PNGs: every frame is decoded and rasterized exactly once, up front, so scrolling never triggers image decoding or geometry math. The scroll handler's only job is a single drawImage() blit of an already-painted bitmap — the cheapest possible paint the canvas API offers.

A numeric playhead object is what actually gets tweened

GSAP can't tween a canvas, so the snippet tweens a plain proxy object: gsap.to(playhead, { frame: FRAMES - 1 }). The tween's onUpdate rounds playhead.frame to an integer index and blits that frame. This proxy pattern is the standard way to scrub any non-DOM target — video currentTime, WebGL uniforms, chart data — because ScrollTrigger just needs *some* number to interpolate between its start and end.

Pinning turns scroll distance into a timeline

The stage is pinned with start: 'top top' and end: '+=250%', so the section holds still while two and a half viewport-heights of scrolling map onto the 80 frames — roughly 20px of scroll per frame, enough resolution that the motion reads as continuous. scrub: 0.4 adds a short smoothing window so trackpad flicks glide between frames instead of stuttering, while still snapping to the scrollbar within half a second.

Why Math.round and not floor

The playhead arrives as a float (frame 37.6), and Math.round picks the nearest frame in either direction. Flooring would bias the sequence backward — you'd only see frame N once you'd fully passed it — which makes reversing feel laggy by one frame. Rounding keeps forward and reverse playback symmetric.

The frame counter is part of the same update

The caption's "Frame 38 / 80" label updates inside the same onUpdate as the blit, so the number and the pixels can never drift apart. font-variant-numeric: tabular-nums keeps the counter from jittering horizontally as digits change width.

Swapping in real exported frames

To use a real sequence, replace the procedural loop with an Image() preloader: build URLs like frame_0001.jpg … frame_0080.jpg, push each loaded image into frames, and start the ScrollTrigger once Promise.all resolves. Everything downstream — the proxy, rounding, and blitting — stays identical, because drawImage() accepts images and canvases interchangeably.

Canvas resolution is decoupled from display size

The canvas's attribute size (640×400) fixes the bitmap resolution, while CSS scales it down responsively with width: min(640px, 92vw) — downscaling a fixed bitmap always stays sharp. For retina-crisp output, multiply the attribute size by devicePixelRatio, render frames at that resolution, and keep the CSS size unchanged; every drawImage call then blits at native density. Because the frames were pre-rendered at the same resolution as the visible canvas, no per-frame scaling interpolation happens during the scrub — the blit is a straight memory copy.

Customizing it

Raise FRAMES for smoother motion (120–150 for hero sequences), stretch end for a slower scrub, or layer HTML captions that fade in at timeline positions alongside the canvas. Pair it with a scroll zoom hero for the section before, a scroll text clip reveal for copy, or a scroll parallax layers section after the sequence ends.