This entire page is one WebGL texture — a proof of concept, not a product. Flick the scroll wheel — or swipe hard on mobile — and a directional blur shader smears the pixels along your velocity vector, like a long camera exposure nobody asked for.
Both buttons are, of course, part of the image.
Three stages, all invisible to you — like the rest of the page, technically.
On load, html2canvas takes a screenshot of the page you think you're reading right now — same-origin only, so no security prompts.
The snapshot is sliced into GPU-friendly tiles and uploaded as WebGL textures. The real DOM is hidden but keeps its height, so the scrollbar still works. It is the only part of this page that's real.
Every frame, scroll velocity drives a multi-tap directional blur shader. Fast flicks stretch the pixels; at rest the page is perfectly sharp, so you'd never suspect a thing.
“Motion blur is the difference between a page that scrolls and a page that moves.”
Real quotes from real users of this entirely hypothetical product.
“I never knew my scrolling had a motion-blur problem. It didn't. Thank you for solving it anyway — I honestly can't imagine going back to whatever was perfectly fine before.”
“So many websites these days are just boring documents you scroll and read. Finally: a real-time GPU rendering of a screenshot of a boring document you scroll and read.”
“Readability while scrolling is genuinely improved. Text I wasn't reading used to fly past sharp; now it flies past blurred, which is how my eyes always intended it. Comprehension is unchanged, but it feels faster.”
“I arrived with three criticisms and read the other testimonials first. All three had already been addressed — as compliments. There is nothing left for me to do here. Five stars.”
CSS filters can fake a blur on scroll, but filter: blur() is an isotropic Gaussian — it fogs the whole element equally in every direction. Real motion blur is directional: pixels streak along the axis of movement, proportional to speed, like film exposed while the camera pans.
Doing it properly means controlling every pixel yourself. So this page snapshots its own DOM into a texture, hides the original, and re-renders the visible slice through a fragment shader that samples the texture 31 times along the scroll direction. The offset between taps is your scroll velocity times a virtual shutter time.
Because the shader reads a pre-rendered texture, nothing touches layout or paint during scrolling — the browser only composites one canvas. That is what keeps it smooth on a phone.
Is any of this a sensible way to ship a website? Absolutely not — which is why this is a concept demo and not a framework. But as a way of making pixels do something they shouldn't: extremely.
This section exists purely to give you runway. The words here don't matter — though, since you're reading a texture, that was already true.