A forest glyph that wouldn't quite render right

Every forest in the directory has a glyph — three concentric rings, counter-rotating; a tracer dot orbiting the inner one. It carries the same visual idiom as the breathing rings in Constellation and the orbital rings in Folk. The system is the icon, miniaturised.

A single glyph runs smoothly on any device. The trouble was that the directory shows several at once — every visible forest in a scrolling list. Five or six glyphs, each animating sixty times a second.

On an emulator it was fine. On a real phone it stuttered.

Before — five glyphs animating at once on a physical phone

What was actually happening

The animation itself wasn’t the problem; the render path under it was. The glyph was drawn through a vector layer that lives on the native side of a bridge — every frame, every rotation, every ring sent a small message across that bridge to schedule a redraw. One glyph at sixty frames a second is fine. Five glyphs, each carrying three independent rotations, isn’t — around twenty bridge messages per frame, all queued on the same thread the screen uses to paint.

The animations stayed fast in isolation. The rendering thread couldn’t keep up. Frames dropped in twos and threes — exactly the cadence the eye reads as stutter.

The fix

The glyph was rewritten to draw directly to a GPU canvas instead. Same three rings, same counter-rotation, same tracer dot — but they live on a single surface that the GPU repaints in one pass. No bridge messages, no per-ring scheduling, no per-frame indirection. The work that used to multiply linearly per glyph collapses into a single canvas update.

The animation runs from one shared clock on the UI thread; each ring reads the clock and computes its own angle in a worklet. No timers, no per-component animation drivers — just math, on a thread that doesn’t have to ask anyone else to schedule a redraw.

After — same animation, no dropped frames

The other half

The glyph fix was half the work. The directory itself has on the order of twelve thousand forests; mounting every row up front isn’t an option, glyph cost or not. The list is windowed — only a few viewports of rows are mounted at any moment, and as you scroll, rows further off unmount while new ones come in. Scroll position is preserved by the math, not by force.

It’s the same shape of solution a personal forest already uses for its message canvas, just applied to a directory rather than a chat thread — the same kind of windowed scroll.

The lesson

Visual fidelity is one budget; render-path cost is another. Something that’s smooth in isolation can be laggy in aggregate not because the animation is bad, but because the path it takes to the screen multiplies poorly.

Tech notes

The render path the post describes maps to two specific libraries. The old version used react-native-svg; the new one uses @shopify/react-native-skia.

Skia is a 2D graphics library Google bought in 2005 and open-sourced in 2008. It’s the renderer behind Chrome, Android, Flutter, and Firefox — a mature C++ engine with a unified drawing API that targets Metal on iOS and OpenGL or Vulkan on Android. @shopify/react-native-skia is the React Native binding for it. Shopify started the project in late 2021; William Candillon and Christian Falch were the original authors.

The speed gain has two independent components that combine. The first is JSI — React Native’s newer plumbing that lets JavaScript hold direct references to native C++ objects and call them synchronously. The old “bridge” passes property updates as serialised messages; JSI passes pointers. The second is Skia’s GPU canvas: instead of a tree of native views that each need invalidation and rasterisation, the whole drawing lives on one hardware-accelerated surface that the GPU repaints in a single pass.

The Skia binding keeps the drawing’s source-of-truth on the UI thread rather than the JS thread. Combined with the worklets this post mentioned — small functions that run on the UI thread — an animation can read a shared clock, compute the next frame, and push pixels to the GPU without ever touching JS. A stalled JS thread — garbage collection, a slow component render, a network response — can’t drop frames in an animation that never asks JS for anything.

The tradeoff is binary size. Skia is a heavy native library: roughly 4 MB extra on Android, 6 MB on iOS per Shopify’s docs. Worth it for animated and canvas-heavy surfaces; overkill for static icons, where react-native-svg’s lighter view-tree path is the right choice.

The same batch also rebuilt the directory’s row list on top of list virtualization — the technique behind every “infinite scroll” surface you’ve used. Rather than mounting one element per item — which at the directory’s twelve-thousand-forest scale would mean twelve thousand glyphs, scroll handlers, and accessibility nodes all alive at once — only the rows visible on screen plus a small buffer are kept mounted. As the reader scrolls, off-screen rows unmount and newly-visible ones mount in their place. Memory and CPU usage stay roughly constant regardless of how long the underlying list is.

Two parameters keep it stable under real scrolling. Window size controls how many viewports of rows stay mounted around the visible area — small enough to bound the cost, large enough to absorb a fast scroll without showing blank rows. Render batching caps how many rows can mount in a single frame, with a short pause between batches. Without it, a long fling can queue hundreds of mount operations at once and block the main thread — producing exactly the kind of stutter the rest of this post is about.

Pagination — the data-fetch side — completes the picture. Fetch one page when the reader nears the bottom; request the next when they near it again. Combined with virtualization, the app never holds the whole directory in memory; only the rows actually being looked at, plus a small lookahead.