Bad Apple!! ASCII
frmlinn · Animation

Click inside the demo to interact. Use Prev / Next to switch. About this demo · All demos · Awesome · Guides

Pretext demo case study

About Bad Apple!! ASCII

The legendary Bad Apple!! shadow art video becomes a real-time browser typography demo: silhouettes, motion, and rhythm are recreated with text glyphs instead of bitmap frames. It is a strong showcase for Pretext because the effect only works when characters can be measured and placed predictably at

Animation Built by frmlinn 500+ words AnimationASCIIViral

The legendary Bad Apple!! shadow art video becomes a real-time browser typography demo: silhouettes, motion, and rhythm are recreated with text glyphs instead of bitmap frames. It is a strong showcase for Pretext because the effect only works when characters can be measured and placed predictably at animation speed.

What It Does

Bad Apple!! ASCII turns the music video's high-contrast shapes into a field of text characters. Dark and bright regions are represented by different glyph densities, so the viewer sees recognizable silhouettes even though the screen is made from typography. The result sits between ASCII art, motion graphics, and a stress test for text rendering: the content changes rapidly, the perceived image depends on precise character spacing, and every frame has to remain visually coherent.

Unlike a static pre-rendered ASCII video, this demo makes the text layer feel alive in the browser. It shows why Pretext is interesting for creative coding: text can become pixels, particles, masks, and animation material while still being real measurable glyphs.

Technical Highlights

The core challenge is stability. Browser DOM measurement is too expensive to repeat for every character across an animated scene, especially if the layout must respond to viewport changes. Pretext solves that by separating measurement from layout. Character widths are prepared for the selected font, then the animation loop can place glyphs using cached metrics and arithmetic instead of asking the DOM for dimensions.

That architecture matters because ASCII-like animation is sensitive to small errors. A wide glyph, a narrow glyph, and a whitespace region do not occupy the same visual weight. Pretext lets the renderer account for those differences without turning every frame into a layout reflow problem.

Pretext APIs Used

API Purpose
prepare() Cache text and font measurements before animation
layout() Compute reusable line positions for the text grid
Canvas rendering Draw the animated glyph field efficiently
Cached glyph widths Preserve visual density across frames

How to Try It

Open Bad Apple!! ASCII on pretext.cool and let the animation run for several seconds. Resize the browser or open the solo view to see how the scene adapts to the available canvas. For developers, the useful takeaway is not only the visual effect; it is the rendering pattern: measure once, animate many times, and keep the browser's layout engine out of the hot path.

Built By

Created by frmlinn. Source code is available on GitHub. The demo is part of the pretext.cool community collection and pairs well with the Pretext examples, Pretext API reference, and the broader guide to creative Pretext demos.

Why this matters for Pretext developers

Bad Apple!! ASCII is useful because it makes text layout visible as a programmable system, not a browser side effect. The same idea applies to production UI work: chat messages, virtual lists, dashboards, canvas editors, rich-text tools, localized interfaces, and animated typography all benefit when text size can be predicted before rendering.

Pretext keeps that loop predictable. prepare() captures the expensive font and segment measurements once, while layout() can be reused at different widths without triggering DOM reads. That separation is what lets interactive demos stay responsive while still using real text, real glyph widths, and real line wrapping.

When evaluating this demo, inspect how the text responds to resizing, pointer input, animation timing, and repeated state changes. Those are the moments where traditional DOM measurement usually becomes fragile: hidden measurement nodes drift from the real render tree, layout reads force synchronous reflow, and rapid updates produce visible jank. A Pretext-based implementation keeps the measurement model explicit, which makes the behavior easier to port into real product interfaces.

Related Pretext resources