The newest spline work (hyperbezier) is still on the back burner, as I'm refining it. This turns out to be quite difficult, but I'm hopeful it will turn out better than the previous prototype you saw.

“The first volume of Knuth's series (dedicated to the IBM 650 computer, "in remembrance of many pleasant evenings") was printed in the late 1960s using old-fashioned but beautiful hot-type printing technology, complete with Linotype machines and the sharp smell of molten lead. Volume 2, which appeared a few years later, used photo-offset printing to save money for the publisher (the publisher of this book, in fact). Knuth didn't like the change from hot type to cold, from Lino to photo, and so he took a few months off from his other work, rolled up his sleeves, and set to work computerizing the business of setting type and designing type fonts. Nine years later, he was done.”

What projects like Slug and Vello rather show is that GPU coding remains so obtuse that you cannot tackle an isolated subproblem like 2D vector rendering, and instead have to make apple pie from scratch by first creating the universe. And then the resulting solution is itself a whole beast that cannot just be hooked up to other API(s) and languages than it was created for, unless that is specifically something you also architect for. As the first slide shows, v1 required modern GPUs, and the CPU side uses hand-optimized SIMD routines.

2D vector graphics is also just an awkward niche to optimize for today. GPUs are optimized for 3D, where z-buffers are used to draw things in an order-independent way. 2D graphics instead must be layered and clipped in the right order, which is much more difficult to 'embarrassingly' parallelize. Formats like SVG can have an endless number of points per path, e.g. a detailed polygon of the United States has to be processed as one shape, you can't blindly subdivide it. You also can't rely on vanilla anti-aliasing because complementary edges wouldn't be fully opaque.

Even if you do go all the way, you'll still have just a 2D rasterizer. Perhaps it can work under projective transform, that's usually pretty easy, but will it be significantly more powerful or extensible than something like Cairo is today? Or will it just do that exact same feature set in a technologically sexier way? e.g. Can it be adapted to rendering of 3D globes and maps, or would that break everything? And note that rasterizing fonts as just unhinted glyphs (i.e. paths) is rarely what people what.

I expect the line segments are represented by their two end points.

This makes it easy to encode which side is fill vs. alpha, by ordering the two points. So that as you move from the first point to the second, fill is always on the right. (Or vice versa.)

Another benefit of ordering at both point and segment levels, is from one segment to the next, a turn to the fill side vs. the alpha side, can be used to inform clipping, either convex or concave, reflecting both segments.

No idea if any of this what is actually happening here, but this is one way to do it. The animation of segmentation did reflect ordered segments, and clockwise for the outside border, and counterclockwise for the cavity in R. Fill to the right.

2. I skipped over this in the interest of time. `Nevermark has the central insight, but the full story is more interesting. For each tile, detect whether the line segment crosses the top edge of the tile, and if so, the direction. This gives you a delta of -1, 0, or +1. Then do a prefix sum of these deltas on the sorted tiles. That gives you the winding number at the top left corner of each tile, which in turn lets you compute the sparse fills and also which side to fill within the tile.

[1]: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...

There are different applications for 2D rendering.

In our case we need support for the rendering to take place with f32/float precision, i.e. RGBA colors need to be 96 bit values.

We also do not care if the renderer is realtime. The application we have is vector rendering for movie production.

That's where the multiple backend approach of vello and especially the vello-cpu crate become really interesting. We will either add the f32 support ourselves or hope it will become part of the vello roadmap at some stage.

Also, Blend2D is C++ (as is Skia, the best alternative, IMHO). Adding a C++ toolchain requirement to any Rust project is always a potential PITA.

For example, on the (Rust) software we work on, C++ toolchain breakage around a C++ image processing lib that we Rust-wrapped cost us two man weeks over the last 11 months. That's a lot for a startup where two devs work on the resp. affected part.

Suffice to say, there was zero Rust toolchain-related work done or breakage happening in the same timeframe.

You are correct that conflation artifacts are a problem and that doing antialiasing in the right color space can improve quality. Long story short, that's future research. There are tradeoffs, one of which is that use of the system compositor is curtailed. Another is that font rendering tends to be weak and spindly compared with doing compositing in a device space.

What should we be using in 2025? I thought pre-multiplied alpha is essentially what you go for if you want a chance of alpha compositing ending up correct, but my knowledge is probably outdated.