It's work in progress. I was hoping to get more done on the renderer but various things have been slowing me down. But lately I've been feeling a new burst of energy, so hope to have something more to show before long.

I agree that the talk raises a lot of questions. Hopefully that's a good thing, as I think they deserve the attention of curious people!

Regarding the mismatch between 3D hardware and 2D rendering, we'll need hard empirical numbers, but the approach I'm taking is basically to write a software renderer (not unlike Cairo or even libart which predates it), just one that's designed for massive parallelism so it can run on the GPU. This will have performance characteristics more similar to Cairo (just faster as so much more throughput is available) than rasterization-based approaches. The latter really fall down when there's soft clipping and lots of blending, as that requires generation of intermediate texture buffers. I do address this in the talk :)

I hope I will have more solid answers for some of these questions before long.

I'm experimenting with GPU based 2D rendering using signed distance functions as drawing primitives for quiet a long time now. My experience is that as soon as the object tree exceeds a certain size the CPU will always beat the GPU. The only way the GPU can win is when you have high complexity drawing primitives and a low amount of objects which is exactly the opposite one usually encounters in the real world. Maybe the partitioning approach you are proposing will help but only real world implementations and benchmarks will tell.

I'm using partitioning in Pathfinder and it works quite well. It's not hard to beat the CPU. The forerunner of these approaches is the "Massively Parallel Vector Graphics" paper, if you're interested.

It's interesting to note the parallels (no pun intended) with raytracing, in which everyone said it was impossible to improve over the CPU right up until people discovered how to effectively partition with acceleration structures and now raytracers are doing more and more on GPU.

I recently-ish wrote a GPU based renderer for a GUI toolkit. I haven't put a ton of effort into optimisation, so I wouldn't be surprised if for smaller windows with lots of elements the GPU renderer was slower, but once you get to high-dpi displays with larger windows the CPU approach hits its limits. I don't have hard numbers, but we went from an unusable ~15fps at 8k resolution to hitting our target of 60fps with the GPU renderer.

If you use froward rendering, which means placing a bunch of textures on the screen, you are not really "drawing". We are probably not talking about the same thing.

It's not as complex has say drawing SVGs, but I've implemented Bezier curves, stippled lines, arbitrary rounded rectangles (html style) and subpixel-antialiased font blitting. I'd say that's far from just "placing" a bunch of textures.

Building a 2D signed distance field renderer that works similar to Dreams, setting pixels instead of emitting a pointcloud, would allow for complex object trees with lots of edits and perform well on the GPU.

Some classes of 2D rendering are faster on the CPU, but not all, though.

But even if it is slower, there may be advantages of moving the rendering to the GPU, like leaving the CPU to do other stuff, less power usage overall, more RAM available, etc.

So far no pure GPU 2D rendering exists. Skia moves some tasks to the GPU that and leaves others to the CPU. This is the worst of both worlds because you need as much memory as before but you have more bandwidth pressure on th PCIe bus and at the same time you are waking up two devices from sleep states instead of one which will consume more power. Then you have the additional problem of security domains on GPUs which complicates things even further. I have serious doubts that GPU based 2D rendering in a way that it is done today will help performance or reduce power consumption at all.

The key word here is "forward rendering". There exists no forward rendering primitives on GPUs besides triangles.

> I have serious doubts that GPU based 2D rendering in a way that it is done today will help performance or reduce power consumption at all.

Your doubts are entirely unfounded. Every mobile device uses Skia-style hybrid GPU/CPU rendering entirely due to performance, and power consumption didn't take a hit from it.

There's a question of why this hasn't also happened on desktop, but I think it's just because nobody cares if desktop GUI performance is garbage. It's not touch-driven, so it's less noticeable. It's not front & center on reviewer comparisons like it is/was for iOS vs. Android. And since so much is web-based, the number of commonly used GUI desktop apps has plummeted.

And on platforms where Cairo is relevant there's bigger problems in graphics than rendering speed anyway, like the abysmal state of composition foundations (aka, X11 still being so common and wayland being stuck in permanent not-quite-there).

Isn’t Quartz GPU accelerated on OSX?

Does https://developer.nvidia.com/nv-path-rendering qualify?

The state of the art on path rendering, both academic approaches such as Random Access Vector Graphics (Hoppe and Nehab), Massively Parallel Vector Graphics (Ganacim et al) and more practical implementations such as Slug (Lengyel), Pathfinder (Walton) have advanced considerably beyond NV path rendering. I also hope to do considerably better - my approach is most similar to Pathfinder but with more of the expensive CPU operations moved to GPU.

I'd like to humbly suggest that Rasterizer may have extended the state of the art of 2D GPU-accelerated rendering: https://twitter.com/Vector_GL/status/1214507005316128768