The six Violet captures show how several layers contribute to the same composition.

It begins with little more than a violet field and unstable electric lettering. A particle network then spreads across the frame, producing links and translucent polygonal surfaces. Later, circular masses of square cells appear, lightning crosses the image, softer atmospheric shapes accumulate behind the geometry, and bloom eventually pushes parts of the scene toward near-white intensity.

These effects do not necessarily replace one another. Several layers can remain active while their relative visibility changes. Their visual overlap comes mainly from compositing, not from the layers continuously influencing one another’s simulation state.

Sparse and dense states can use the same underlying systems. Their visible differences depend on particle counts, opacity, field parameters, compositing operations and bloom intensity, rather than requiring an entirely different renderer.

The final image is crystal clear, with fine lines and sharply defined geometry that can look almost like vector graphics, although the canvas output is raster-rendered rather than a resolution-independent vector image. In my experience, it is best presented on large LCD screens, which preserve that crispness and detail. Projectors tend to soften the image and reduce the clarity that gives these compositions much of their character.

The Forces layer uses moving particles whose velocity and connectivity also determine rendering parameters.

Particle state is calculated in a Web Worker. The worker updates movement and generates links, joints and triangles, while the main thread handles Canvas 2D rendering. This separates simulation work from the main thread, but does not remove the dominant rendering costs of this animation style. The underlying interaction model is stylized rather than physically exact: nearby particles react to one another using distance, mass, drag and boundary reflection.

Velocity is then reused as a visual parameter.

Faster motion can strengthen and thicken links, while particle radius and lightness decrease. Highly connected points can receive glowing joints, and connected triples can become translucent triangular surfaces. The triangles are derived from the existing connection graph rather than from Delaunay triangulation or a conventional mesh generator.

The simulation therefore supplies both positions and drawing data: link weights, joint markers and triangular surfaces.

Sweeper works almost in reverse. Its cells sit on a fixed grid, normally about 18 pixels apart. The coordinates themselves do not move. Instead, circular influence fields travel across the grid and temporarily change the cells they reach.

A field has a center, radius, propagation speed, width, maximum cell size, shape and blend mode. A cell reacts most strongly when it is close to the moving wavefront, roughly when the difference between its distance from the center and the field radius becomes small:

Here d is the cell’s distance from the field origin and r is the current radius.

Visually, this can resemble an expanding object or explosion. Technically, the geometry remains stationary. What changes is its size, color, shape and composition.

Fields can render squares, circles or five-point stars, and overlapping fields can produce multiple rendered instances at the same grid coordinate. Blend operations such as difference, color-burn, hard-light, color-dodge can make identical motion produce very different images.

Sweeper also contains moving agents, some of which are rendered as luminous “suns” using layered radial gradients. Their movement can follow predefined GSAP paths, including BPM-derived durations, or switch into a gravitational mode.

The gravity mode uses softened inverse-square attraction:

Additional damping, speed limits, boundary forces and collision handling stabilize the motion. It is deliberately art-directed physics rather than an exact orbital simulation.

Collisions also produce events outside the motion calculation.

A collision position is returned to Sweeper and used to create a new influence field. This is a local interaction within Sweeper, not a general coupling between Eraser’s separate rendering layers.

Eraser uses typography in two different ways.

Regular DOM text provides credits, track information and repeated titles, often combined with blend modes. Separately, Sweeper loads font data and extracts glyph coordinates so that lettering can be treated as geometry.

Those coordinates can be filled and electrified with short lightning fragments, producing the unstable lettering visible in sequences such as Violet. The font is not rendered as a perfect typographic outline; it becomes source material for another procedural effect.

Glyph coordinates are reused as input to the procedural drawing code, in the same way that velocity supplies link weights and collision coordinates supply field origins.

Glow, branching lines and repeated shapes add light and texture to the composition.

Bloom adds a luminous version of the Sweeper geometry to the composition. At higher intensity, individual cells can merge into large fields of light, as in the later Violet states.

Lightning is generated using recursive midpoint displacement. A straight segment is repeatedly subdivided, its midpoints shifted sideways by random amounts, and the displacement reduced at each step. The result is unpredictable in detail but still constrained by clear endpoints and rules.

The same principle appears in the petal system. Its rosette-like forms are not constructed from individual petals; they emerge from overlapping circles arranged on a lattice. Complex-looking geometry comes from simple primitives interacting.

The final layer is control.

Eraser’s scene manager connects keyboard events, MIDI values, timed callbacks and visual parameters. MIDI values from 0–127 are normalized into values that can directly influence the graphics. One control bank affects Forces parameters such as links, particle count, drag, mass and size; another controls fields, suns, gravity and bombs; a third reaches into shader opacity and bloom.

Velocity can also affect the behaviour of an action. A color transition, for example, can range from roughly ten seconds to about 100 milliseconds depending on how strongly the MIDI pad is triggered.

These mappings allow scene actions and parameter transitions to be triggered while the layers continue rendering.

The controls change simulation and rendering parameters, rather than selecting only from finished images.

Eraser combines TypeScript, Vite, Canvas 2D, Web Workers, Three.js, GLSL, GSAP, TinyColor, simplex-noise and font processing.

Canvas handles immediate drawing. A worker handles particle simulation. Three.js handles bloom and other GPU-oriented tasks. GLSL provides procedural shading. The DOM remains part of the composition rather than merely surrounding it.

The main performance constraint in this Canvas 2D-heavy approach is not usually the particle calculations. A likely bottleneck is GPU pixel-processing throughput, particularly alpha blending, overdraw and compositing: overlapping transparent shapes can cause the same pixels to be processed repeatedly, even within one canvas. Rasterization and moving image data through the browser’s rendering pipeline can add further costs. A Web Worker does not make those operations cheaper, and a more powerful discrete GPU does not necessarily make this workload faster. Canvas 2D uses a browser-managed rendering path rather than giving the application direct control over GPU work as WebGL does.

There are two distinct stages here. Canvas 2D applies globalAlpha and globalCompositeOperation while drawing into each canvas surface; Chrome’s compositor then combines the overlapping canvas and DOM layers, including their CSS blend modes. The second stage cannot explain the slowdown on its own: I encountered performance problems with Forces on a single canvas, drawing only a few hundred points or fewer, together with links, changing circle radii and alpha blending. That points toward costs within the canvas drawing path, not just the final composition of stacked layers. It does not by itself establish whether pixel throughput, path rasterization, drawing calls or frequent drawing-state changes dominate; that distinction requires profiling.

In my experience, Eraser runs better on Apple Silicon than on machines with otherwise powerful discrete GPUs. That is an observation about this workload, not a general GPU ranking: browser implementation, memory bandwidth, data transfers and hardware architecture can matter more here than headline graphics performance. Apple Silicon’s unified memory is relevant to that distinction, although these observations alone do not establish which part of the pipeline causes the difference.

The implementation demonstrates several ways of reusing simulation data across rendering layers: velocity changes geometry, fields alter a stationary grid, collisions create new fields, and glyph coordinates become input for lightning. The resulting image depends on both those calculations and the browser’s compositing of their outputs.

Development of Eraser is discontinued for now. I do not expect substantial further evolution of this tool; the source and recordings document its current state rather than an active roadmap.

My next visualization and graphics work will probably focus on 3D and Three.js. That is a likely direction for separate experiments, not a planned next phase of Eraser.