Building an Animated Logo with Clipper2 and WebAssembly

Most logo animations rely on simple transforms: scale, rotate, and fade. I wanted something different for my portfolio: a tree that grows by having its SVG path geometry inflate in real-time. Not just a scale animation because that takes the whole finished shape into account. A morph didn't work either because the line offsets end up looking super janky. I needed something that felt organic.

This post covers the journey of building that animation, from the initial concept through the technical challenges of compiling Rust to WebAssembly and integrating it with GSAP's animation timeline.

The Concept

My portfolio logo features a olive tree growing out of a git main branch. The animation I envisioned was:

1. The branches draw in with clip-path reveals, because they are fast and technical they can just form.
2. The tree starts to grow out of the main branch. This would ideally grow in a more organic fasion.
3. Leaves and olives pop in with scale animations on the tree.
4. A white shadow fades in at the end to outline the entire logo.

The tricky part is step 2. SVG doesn't have a native "inflate/deflate" operation. CSS scale would just make the tree bigger; it wouldn't change the path geometry. What I needed was polygon offsetting: taking every edge of the path and moving it inward (deflate) or outward (inflate) by a fixed distance.

Architecture Overview

The system has four layers:

Clipper2 (polygon offsetting engine)
    ↓
clipper_offset.wasm (Rust → WebAssembly)
    ↓
OffsetPathPlugin.ts (GSAP plugin)
    ↓
AnimatedLogo.tsx (React component)

React manages the SVG elements and refs. GSAP handles the animation timeline and easing. The custom GSAP plugin bridges JavaScript and WebAssembly. Rust/WASM does the heavy computation: parsing SVG paths, flattening Bezier curves, running Clipper2, and converting results back to SVG.

The GSAP Plugin

GSAP is the animation engine driving the entire logo sequence. To integrate path offsetting, I wrote a custom GSAP plugin called OffsetPathPlugin.

Plugin Structure

export const OffsetPathPlugin = {
  name: "offsetPath",

  init(target, value, tween) {
    // Store original path, parse options, read current offset
  },

  render(progress, data) {
    // Interpolate offset, call WASM, update SVG path
  },
};

The plugin intercepts offsetPath in GSAP's tween vars:

// Deflate the tree to nothing
gsap.set(treePathRef, { offsetPath: { offset: -45, originX: 0.1, originY: 1.0 } });

// Animate it growing to full size
gsap.to(treePathRef, { offsetPath: { offset: 0, originX: 0.1, originY: 1.0 }, duration: 2 });

Tween Chaining

One challenge was making gsap.set() chain properly with gsap.to(). Each tween creates a fresh plugin instance, so state can't live on this. The solution was tracking the current offset on the target element itself:

// In render():
(data._target as any).__gsapOffsetPath = offsetAmount;

// In init():
(this as any)._startOffset = (target as any).__gsapOffsetPath ?? 0;

This way, when gsap.set(el, { offsetPath: -45 }) runs, it stores -45 on the element. When the subsequent .to(el, { offsetPath: 0 }) starts, it reads -45 as the starting value and animates to 0.

Graceful Degradation

When the offset is very negative, Clipper2 deflates the path to nothing; there's no geometry left. Rather than throwing an error, the plugin hides the element with visibility: hidden and reveals it once the offset produces visible geometry:

if (!result || result.trim() === "") {
    data._target.style.visibility = "hidden";
    return;
}
data._target.style.visibility = "visible";
data._target.setAttribute("d", result);

Lessons Learned

Clipper2 is picky about input. Winding order, path closure, and coordinate precision all matter. Silent failures (empty results with no error) make debugging difficult. Adding extensive console logging from WASM was essential.

GSAP's plugin API has subtleties. The this.add() method for creating PropTweens didn't behave as expected with custom properties. Manual interpolation using the progress parameter was more reliable and easier to reason about.

WebAssembly is fast enough for animation. Running Clipper2 on every frame (60 FPS) with a 248-point path works smoothly. The entire offset computation takes less than a millisecond per frame.

Bounding-box anchoring is simple but effective. The translate-after-offset approach for pinning an anchor point is easy to implement and produces convincing "growing from a point" animations without modifying the offset algorithm itself.