Faster, easier 2D vector rendering [video]

Fun story.

The Ministry of Education was using MS Gothic for printed student transcripts. To help students send transcripts directly to post-secondary schools, the Ministry wanted to shift from paper to digital copies. This meant producing a PDF file that had like-for-like characteristics with the printed copy.

Legally, Microsoft requires licensing MS Gothic if the font is used in server-side generated documents. I raised this issue with the Ministry as part of my work in recreating the transcripts. MS Gothic proved to be cost-prohibitive and I suggested they used Raph Levien's unencumbered Inconsolata Zero instead, which is a near-perfect drop-in replacement for MS Gothic and drew inspiration from Letter Gothic.

Now, the stakeholders for the Ministry of Education are extremely protective of the transcript format and there was a subtle, but important difference: The Ministry wanted a non-decorated zero whereas Inconsolata Zero's is slashed. That would not fly with the Ministry.

I, a complete stranger, emailed Raph. The next day, he asked Alexei Vanyashin to set up a custom version of Inconsolata Zero. Alexei went above and beyond to fix all the issues I encountered and about eight days later we had a free replacement for Inconsolata Zero without a dotted zero that passed Ministry scrutiny.

Hard to believe that that was nine years ago.

Aside, my coworkers got a kick of watching me walk down the hall from the printer back to my desk holding two overlapping pieces of paper up to the lights: an official student transcript and my version. This was the technique I used to make sure that the PDF file produced a pixel-perfect replica on paper.

What I love with Raph Levien is how it does exactly the opposite of what most people do in tech: given the current financial incentives, the only thing most people can afford is to do something “good enough” as fast as possible, and in the end we end up with lots of subpar, half-baked solutions that cannot be fixed properly because many people rely on the tool they have and fixing it in depth would break everyone's workflow. Until the next solution appears, and given the same structural constraints, end up failing in the exact same shortcomings.

Instead Raph has spent the past 9 years I believe, trying to create a sound foundation on the problem of performant UI rendering.

I don't know how it will go, and he's going to end up shipping his grand vision at all eventually, but I really appreciate the effort of “doing something well” in a world that pretty much only rewards “doing something quickly”.

As someone interested but unfamiliar with the state-of-the-art of GPU vector rasterization I struggle to understand how the method described here isn't a step back from the SLUG algorithm or the basic ~100 lines of glsl of the vector texture approach of https://wdobbie.com/post/gpu-text-rendering-with-vector-text... from nearly a decade ago (albeit with some numerical precision limitations.)

Is the problem here that computing the vector texture in real-time is too expensive and perhaps that font contours are too much of a special case of a general purpose vector rasterizer to be useful? The SLUG algorithm also implements 'banding' which seems similar to the tiling described in the presentation.

Raph - I know enough to be very dangerous with GPUs so please forgive my ignorance. Two questions:

1. Do you have a favorite source for GPU terminology like draw calls? I optimized for them on an unreal engine project but never "grokked" what all the various GPU constructs are and how to understand their purpose, behavior and constraints. (For this reason I was behind the curve for most of your talk :D) Maybe this is just my lack of understanding of what a common / modern pipeline consists of?

2. I replayed the video segment twice but it is still lost on me how you know which side of the path in a tile is the filled side. Is that easy to understand from the code if I go spelunking for it? I am particularly interested in the details on how that is known and how the merge itself is performed.

Raph, are you familiar with Rive[1]?

Their vector rendering implementation is much faster than Skia[2].

How does Vellum compares to Rive in terms of performance?

[1] https://rive.app/

[2] https://x.com/gordonphayes/status/1654107954268782595

Great presentation. However, I have mixed feelings about Vello. On one hand, it's awesome that someone is truly trying to push the GPU to do 2D rendering work. But my impression is that the project has hit some considerable limitations due to the lack of "inter-workgroup" level cooperation in current rendering APIs and difficulties with dynamic memory allocation on the GPU. I'm sure the hybrid rendering scheme they have will be great, as the people behind it are extremely capable, but is that really a meaningful step beyond what Pathfinder achieved years ago? Also, in terms of CPU rendering, Blend2D exists and it's blazing fast. Can Vello's CPU backend really do better?

Is his tattoo an Euler spiral? I made a little explainer for those (feedback welcome)

https://xixixao.github.io/euler-spiral-explanation/

You got a long way to go. Writing a rasterizer from scratch is a huge undertaking.

What's the internal color space, I assume it is linear sRGB? It looks like you are going straight to RGBA FP32 which is good. Think how you will deal with denormals as the CPU will deal with those differently compared to the GPU. Rendering artifacts galore once you do real world testing.

And of course IsInf and NaN need to be handled everywhere. Just checking for F::ZERO is not enough in many cases, you will need epsilon values. In C++ doing if(value==0.0f){} or if (value==1.0f){} is considered a code smell.

Just browsing the source I see Porter Duff blend modes. Really, in 2025? Have fun dealing with alpha compositing issues on this one. Also most of the 'regular' blend modes are not alpha compositing safe, you need special handling of alpha values in many cases if you do not want to get artifacts. The W3C spec is completely underspecified in this regard. I spent many months dealing with this myself.

If I were to redo a rasterizer from scratch I would push boundaries a little more. For instance I would target full FP32 dynamic range support and a better internal color space, maybe something like OKLab to improve color blending and compositing quality. And coming up with innovative ways to use this gained dynamic range.

I was confused by the step where the tiles are generated by tracing the outline and then sorted afterwards. It seems like this could be faster to do earlier (possibly even largely precomputed) using something analogous to oldschool scan conversion or span buffers? I'm not super up to date on this stuff so would love to know why this is faster.

Always amazes me when the cost of computing the optimized draw regions as shown in the slides is worth the savings even on CPU.

Great presentation and thanks for sharing the slides. Wondering, can any of these methods be used for 3D too?

Excellent presentation - I like that the design bakes in rendering efficiency from the get go.

is there a document or reference implementation that describes the full algorithm? tiling, sorting, merging, and strip conversion.

Is there any specific connection between Rust and the netherlands? A friend of mine helped organize a big rustcon in Delft a while ago, I think Raph spoke there too.

Oh and a question for Raph, did the new spline you invented end up being integrated in any vector/font-creation tools? I remember being really impressed when I first tried your demo

[dead]

Very nice.