GPUs have evolved away from being strictly triangle rasterizers. There are compute shaders that can do general purpose computing. The approach described here could in theory be set up by "drawing" a single quad - the whole screen, and it doesn't even need compute shaders but can be implemented using conventional vertex/fragment shaders with global buffer access (in OpenGL, UBOs or SSBOs).

There is a well-known paper that describes an approach how to draw bezier curves by "drawing" a single triangle. Checkout Loop-Blinn from 2005.

Ah yes, the https://en.wikipedia.org/wiki/Implicit_curve approach to filling curves. I have implemented a GPU vector renderer using that: https://github.com/Lichtso/contrast_renderer Here the implicit curve filling extracted as a shader toy: https://www.shadertoy.com/view/WlcBRn

It can even do cubic rational bezier curves, resolution independently. And to my knowledge it is the only renderer capable of that so far.

Your project sounds very impressive. I would like to try it out, unfortunately I'm unlikely to be able to get it to run by building Rust. If I understand correctly it should be able to run it on the Web, you have a demo somewhere? Or a video?

There is a WASM based web demo on GitHub: https://lichtso.github.io/contrast_renderer/

You will need to try different nightly browsers (I think Chrome works ATM), because the WebGPU API changes and breaks all the time. Also don't forget to enable WebGPU, you can check that here: https://wgpu.rs/examples-gpu/

The WASM port is highly experimental: It currently does not use interval handlers. So for animations to run you need to constantly move the mouse to provide frame triggering events. In WebGPU MSAA is limited to 4 samples ATM, so anti aliasing will look kind of bad in browsers. And the keyboard mapping is not configured, so typing in text fields produces gibberish.

That's a bummer, I tried with Chrome and Firefox but no luck. Can't be arsed to try different versions or obscure settings right now.

2 years ago I had a similar experience with WASM/WebGL, I tried to make use of emscripten in a sane way but it was painful to get things like event handling, file I/O and quality graphics to work. Results weren't great. When using specific libraries and coding the app in the right way from the start, porting GPU applications to the Web is allegedly easier.

If you could provide a fool-proof description how to build and set the project up in a few minutes, I would very much be willing to try your project out, it still sounds great. Or provide a few screenshots/videos just to get the idea across how it looks.

Seeing that this is from Microsoft research, and that Microsoft's font renderer has always looked nicer (and is known to be GPU-rendered to boot) makes a lot of sense.

Still, my point stands that this is relatively uncommon even in the realm of 3d programmers. Unity / Unreal engine doesn't seem to do GPU-side Beizer curve processing, even if the algorithm was researched by Microsoft from 2005.

What font renderer do you mean? I don't know about the internals of Microsoft renderers but vector graphics and font rasterization generally are distinct disciplines. This has started to change with higher-resolution displays, but font rasterization traditionally has been a black art involving things like grid snapping, stem darkening etc. Probably (but can't back this up) the most used font rasterization technologies are still Microsoft ClearType (are there implementations that use GPU??) and Freetype (strictly a CPU rasterizer). Don't know about MacOS, but I heard they don't do any of the advanced stuff and have less sharp fonts on low-dpi displays.

I would also like to know where Loop-Blinn is used in practice? I once did an implementation of quadratic Beziers using it, but I'm not up to doing the cubic version, it's very complex.

Microsoft's DirectWrite font renderer, which has been the default since Windows 7 IIRC: https://docs.microsoft.com/en-us/windows/win32/directwrite/d...

Its a blackbox. But Microsoft is very clear that its "hardware accelerated", whatever that means (IE: I think it means they got GPU-shaders handling a lot of details).

GDI / etc. etc. are legacy. You were supposed to start migrating towards Direct2D and DirectWrite decades ago. Cleartype itself moved to DirectWrite (though it still has GDI renderer for legacy purposes).

https://docs.microsoft.com/en-us/windows/win32/directwrite/i...

I'm not really experienced when it comes to GPU programming, so forgive me if I'm wrong with this, but some of the things you say don't make a lot of sense to me:

> 2d vector graphics include things like "bones" and "tweening", which are CPU algorithms. (Much like how bone processing in 3d world is also CPU-side processing).

Changing the position of bones does seem like something you would do on a CPU (or at least setting the indices of bone positions in a pre-loaded animation), but as far as I'm aware, 99% of the work for this sort of thing is done in a vertex shader as it's just matrix math to change vertex positions.

> Consider the creation of a Beizer curve, in 2d or 3d. Do you expect this to be a CPU algorithm, or GPU algorithm? Answer: clearly a CPU algorithm.

Why is it clearly a CPU algorithm? If you throw the bezier data into a uniform buffer, you can use a compute shader that writes to an image to just check if each pixel falls into the bounds of the curve. You don't need to use the graphics pipeline at all if you're not using vertices. Or even just throw a quad on the screen and jump straight to the fragment shader like I did with my circle vector.

> creation of a Beizer curve: ... clearly a CPU algorithm.

isn't this just a tessellation basically? GPU-based tessellation is very common, mostly for meshes but can be used for line-like figure too.