Reinventing feathering for the Vectorian era

This post from Rive's Head of Runtime Chris Dalton shows how we built a fully vector-based feathering system from scratch. It’s a deep dive into the Rive Renderer, why it’s more performant, and how it solves a problem that legacy specs never could.

March, 2024. GDC. I was talking to a colleague when Sarah Warn, our VP of Growth, came over and asked, “Hey, could you please do glows and shadows?” She wasn’t asking on a whim. Designers had been requesting this for a while. She knew that if we shipped it, it would be huge. 

Our CEO, Guido Rosso, had been pushing for this since my first day. Rive CTO Luigi Rosso, his twin brother, used to joke that the second the Rive Renderer shipped, our first priority had to be glows and shadows, or Guido would start flipping tables. (╯°□°)╯︵ ┻━┻

It was always in the back of my mind. But I also knew I didn’t want to take the typical approach. 

Why Gaussian wasn’t an option

The default way to handle glows and shadows in design software is a Gaussian blur, but that method has a massive flaw. You have to use an image convolution filter, which is computationally expensive. 

Here’s what happens under the hood with traditional blurs:

1. The vector shape is rasterized into a bitmap.

2. A convolution filter is applied across the pixels to simulate a soft edge.

3. The result is a glow or shadow that looks beautiful but is computationally expensive, non-scalable, and no longer a true vector.

And here’s the bigger kicker: Gaussian blur wasn’t even designed for soft edges. 

Carl Gauss, the 19th-century mathematician behind the Gaussian function, wasn’t thinking about soft shadows or glowing effects. He was interested in probability distributions and smoothing noisy data. 

When Gaussian blur made its way into image processing a few centuries later, people discovered it could be used for finding edges. By smoothing out fine details in an image, a Gaussian blur helps algorithms detect where one object ends and another begins. In fact, many edge detection techniques, like the Canny Edge detector, start by applying a blur before identifying high-contrast areas. 

The absurdity is that Gaussian blur was solving a problem we never had. We already knew our edges. Vectors are made of Bézier curves, which define elegant boundaries with mathematical precision. 

It’s like baking a cake from scratch, then mashing it up and asking someone to figure out the ingredients. You had the recipe all along. Why destroy the information just to guess at it later?

It made me wonder, “Why are we rasterizing the vector in the first place? Could we calculate soft edges from the vector curves themselves?”

A Gaussian blur relies on a normal distribution curve (bell curve) to soften an image, but it’s always applied to a rasterized bitmap after the fact. What if we didn’t need that extra step? We already know our edges, so we don’t have to approximate them. Instead of applying a blur after destroying the vector data, we could use the same math directly on our shapes.

That’s where things got interesting. 

The first idea was simple. Instead of running an expensive blur across an entire rasterized image, why not apply a convolution filter only along the edges of a vector? And if we were already working on the edges, could we bypass the convolution filter entirely?

Then I realized: The Rive Renderer was already doing half of this work for anti-aliasing. 

How our Rive Renderer works

When I met Rive’s founders, Guido and Luigi, three years ago, I told them I wanted to rethink vector rendering by building a renderer not shackled by SVG limitations. 

Why? SVG was formalized in 2003, but the vector graphics principles it codified had been around since the 1960s and ’70s. It didn’t introduce anything particularly new — just consolidated decades-old ideas into a spec. And it was finalized before the smartphone revolution, on hardware that looks nothing like what we build for today. 

Modern GPUs are wildly different from the ones vector graphics were invented for. Interactive graphics and real-time design on modern hardware need modern algorithms. Some aspects of the firmly established specs weren't going to translate to this new world, but instead of continuing to shoehorn in the old rules, we could rewrite the spec.

Guido and Luigi understood my reasoning immediately and wanted me to build the renderer for Rive. They knew that for Rive to stand out, they needed to reimagine the entire workflow of interactive design. To do that, we needed our own renderer. So, we built it together.

For backstory, Rive is more than a design tool. It’s a full platform made up of three tightly connected parts: the Editor, the .riv file format, and our open-source Runtimes. The Editor creates interactive graphics. The .riv format holds everything — visuals, logic, state changes. And the Runtimes bring it to life in your app, game, or web experience.

Today, the Rive Renderer smooths jagged edges with triangle-based coverage interpolation, tessellating triangles around vector edges to calculate coverage. Depending on whether a triangle naturally falls clockwise or counterclockwise, it contributes positive or negative coverage to a pixel. This creates anti-aliasing, blending the vector into the background. 

What if we extended that logic to solve our feathering problem?

A better way to feather

Instead of an anti-aliasing ramp that’s one pixel wide, we could extend it to any width based on the feathering strength. And rather than using a simple linear coverage map, we could shape that transition based on a normal distribution curve — or bell curve, just like the one behind Gaussian blur. 

Now, instead of blindly applying a blur across a rasterized image, we’re calculating coverage procedurally. The opacity of the feather at any given point isn’t an approximation. It’s the integral of the normal distribution function. 

The midpoint of the feather is located on the precise edge of the path, so halfway through the bell curve, we hit 50% coverage. That means the feathering effect is halfway blended between the vector color and the background at that exact spot. No guesswork, no pixel sampling, just pure math shaping the effect in real time. 

In other words, we weren’t blurring a rasterized image after the fact. We were generating a true vector feather at the source, using the same math that defines the shape itself. 

Unlike SVG-based blurs, which are treated as post-processing effects, Rive computes soft edges as a fundamental part of the vector itself. In SVG, once a blur is applied, it’s no longer a vector. It’s a rasterized effect layered on top. This makes it expensive to dynamically adjust feathering based on real-time conditions, such as object movement, zooming, or interaction. Rive breaks free from this limitation by treating soft edges as a native property of the shape, allowing for infinitely scalable, real-time adjustments.

This had huge advantages:

• Fully vector-based — no rasterization

• Performance friendly — avoided slow convolution filters

• Scales infinitely — no loss in quality

At this point, flat edges and straight lines feathered beautifully, but the moment I tried it on curves or corners, things broke horribly. 

The hard part: hacking away at the math

Like I said, flat edges feathered beautifully. But real-world shapes have curvature and sharp corners, which get some really ugly artifacts if you try to render them with a 1D sampling of the Gaussian integral. 

A traditional Gaussian blur applies a 2D convolution matrix across an entire image, making curves, corners, and overlapping edges soften naturally and aesthetically. 

To capture this effect, I needed a probability distribution function that handled 2D feathering. The renderer had to account for coverage overlap dynamically, cancelling out redundant contributions where feathered edges met and where pixels were double-counted from tessellations on both sides. 

This meant solving for how coverage builds across the feathering range. I kept returning to the bell curve, where the total area underneath defines opacity at each point. On a flat edge, at the exact middle of the feather width, you’ve integrated half the total area, meaning you’ve hit 50% coverage. But once you introduce curvature, or a corner, that 50% scales proportionately with the strength of the curvature. And once you have curvature NOT in the exact center of the convolution matrix, who even knows what's happening anymore. 🫠 

That’s why I started thinking of it as “halfway through the bell curve.” It’s the precise point of balance, where the feathering effect is halfway between opaque and transparent. It also happens to be the cleanest point to model how curvature behaves.

But real-world curves and corners made things messier. Unlike a Gaussian blur, which smears a simple rasterized image, we had to solve this analytically, computing how each feathered edge contributes coverage in real time. 

I tried hacking around this by tweaking the feather ramp, but it was still wrong. Then I realized I needed a 2D integral instead of a 1D ramp, and the interactions with neighboring edges and corners would need to be captured with full precision.. 

Total nightmare. 

I spent weeks playing with equations, running test cases, and manually adjusting the math. What exactly happens when a cubic Bézier passes through the convolution matrix? How do I capture the softening effect that happens as curvature strength increases? How do two cubic Béziers interact with each other when they both pass through the convolution matrix? How do ALL the curves and ALL the corners interact with each other? Where does the “Subtract Path” feature fit with all of this? 

And to make things even more complex, all this Bézier geometry is tessellated into self-overlapping triangle patches. What is each individual triangle’s specific contribution to the analytic coverage (either positive or negative, depending on how it’s wound)?

😵‍💫😵‍💫😵‍💫

… Why is this getting so complicated?? I don’t know how I know, but I do know this geometric solution will work, and the math will be simple and elegant… But how do I find that math? 🤔

At one point, after I worked out the main integral and was narrowing in on a solution, I asked ChatGPT to solve the integral. It got it wrong. I had to sit down, work out and optimize the math by hand, and eventually landed on a version that worked. 

And when I say worked, I mean it looked identical to a traditional Gaussian blur without actually being one. Even better than a Gaussian blur because it’s done in infinitely scalable vector space instead of a raster image.

The true magic of Vector Feathering is in the Clockwise fill rule and the beautifully simple triangle patches the Rive Renderer tessellates, which naturally wind in the correct directions (clockwise or counterclockwise) as they fold around Bézier curves. The math done inside those triangles turned out to be correspondingly elegant. 

Why hasn’t Vector Feathering been done before?

For decades, vector graphics have been locked into the same rigid specs. You had two fill rules, evenOdd or nonZero, and blurs were spec’d as a post-processing Gaussian blur effect.

The problem is that these specs were designed two decades ago for simple 2D graphics, long before GPU-accelerated rendering existed. Major design tools have been stuck in an outdated process, effectively discouraged from innovation. 

These specs also built a wall between designers and developers. Designers worked within constraints. Engineers implemented them. Nobody talked. But that silence wasn’t because the ideas weren’t there — it’s because the systems didn’t allow for better communication. 

Rive took a different approach. It’s a tool built by designers and developers who together broke down that wall and built a system that serves both sides. It helps that our founders, Guido and Luigi, are twins — a designer and a developer who always worked in sync. That natural collaboration shaped Rive’s vision from the start: a graphics platform that makes it easy for creative and technical voices to speak the same language.

Instead of accepting those constraints, we rethought the entire pipeline, from the editor to the renderer, to create a system that actually makes sense for modern hardware. That meant throwing out some parts of the old spec and building one that serves both designers and developers. 

What you see in Rive’s editor is exactly what you get everywhere Rive runs. It’s a true, scalable vector effect, something no one else could build because they don’t control the full pipeline. Rive is the first to treat soft edges as an inherent property of vector graphics, not a post-processing effect.

It’s not just engineers who feel the difference. Designers have told us that many of the old rules felt like arcane relics and aren’t particularly friendly or intuitive. Rive’s modern approach restores some of the creative freedom they haven’t felt since the heyday of Flash: fast, efficient, production-ready vector graphics.

What’s next?

2.5D rendering: Vector graphics that tilt, rotate, and project into 3D space without losing their sharpness. No more baked-in depth effects or static perspective distortions. 

VR-ready UI: Vector-based UI in VR UI with antialiased edges that stay crisp at any scale, with no need for high-res textures or GPU-heavy effects. 

Tapered strokes: Right now, strokes have a uniform width across an entire path. But what if stroke widths themselves could be Bézier curves? With this, you could draw with natural pen dynamics, create variable-width calligraphy, or generate expressive strokes in real-time. Or even tapered feathers! The feather size itself would be a Bézier curve instead of a constant. 

A 15-year idea becomes reality

Truth be told, I’ve been thinking about path rendering since my NVIDIA internship in 2011. Later, when I joined Google, I had ideas for improving path rendering, but we were locked into SVG specs and W3C standards. Rive was different. The reaction was, “That’s a cool idea. Let’s build it!”

Guido and Luigi knew from the start that if we were going to truly innovate, we couldn’t accept the limitations of existing formats. They saw that breaking free from the mental trap of doing things the same way would open the door to entirely new possibilities and make feathering, motion, and dynamic interactions more powerful and efficient.

And that’s exactly what happened. 

For years, blurs and shadows have been about compromises: rasterization, approximations, and trade-offs in performance and scale. 

We don’t need to compromise anymore.