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”.
There's a funny bit in that vein in Cringley's Accidental Empires:
“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.”
We already have plenty of techniques that are fast enough for classic UI rendering. There is no conceivable bottleneck for the kind of stuff that is on your screen right now. It's not a matter of "doing something quickly" imo, that's an issue specific to the games industry, and largely caused by the need to make entirely custom, animated, textured UIs as a feature for a single product.
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.
My wish is for a fast SVG renderer in the browser. At the moment, basic vector drawing is fast, but almost any use of filters or effects lags the browser. Theres a lot that SVG could do for (web) UI, but won't because it's so slow. Here's a small thought experiment I made a while ago for using SVG for more unconventional webdesign. Sadly it lags a lot.
> We already have plenty of techniques that are fast enough for classic UI rendering. There is no conceivable bottleneck for the kind of stuff that is on your screen right now.
I disagree, you either have the old object-oriented toolkits, which are fast enough but very unpleasant to, or the new reactive frameworks, that offers much better developer ergonomics (and that's why pretty much everybody uses them right now) but have pathological performance characteristics and requires lots of additional work to be fast enough when the number of items on screen is high enough.
By the way you are missing the forest (Xilem) for the tree (Vello) here: the foundational work Raph has been doing isn't just a 2D renderer (Vello), this is just a small piece in a bigger UI toolkit (Xilem) that is aimed at addressing the problem I mention above.
Xilem originally started using the native libraries for 2D rendering (through a piet wrapper he discusses quickly in the video) but ended up being disappointed and switched to making his own, but that's just one piece of the puzzle. The end goal is a fact reactive UI framework.
Out of curiosity, what sort of numbers of elements onscreen do you consider to be high?
Depends on the use case, but a few hundreds is enough make a naive React implementation crawl on mediocre hardware.