Nice work! I’d love to hear about your goals with this project, do you want to get it into PDF or browser engines, or anything like that?

Mark Kilgard surveyed some path rendering engines with a few curves that most have trouble with. It’d be fun to see how Rasterizer stacks up, and perhaps a nice bragging point if you dominate the competition. https://arxiv.org/pdf/2007.12254

Having used the quadratic solver code that you found on ShaderToy (sqBezier), you might be able to shave some cycles by doing a constant-folding pass on the code. It can be simplified from the state it’s in. Also the constant in there 1.73205 is just sqrt(3), and IMO it’s nicer to see the sqrt(3) than the constant, and it won’t slow anything down, the compiler will compute the constant for you. Also, it might be nice to additionally link to the original source of that code on pouet.

Computer graphics is not my field, so forgive my ignorance, but could you explain the pros and cons of your "traditional graphics pipeline" approach and more "modern" approaches (I'm guessing that means doing most of the work in shaders)? At the moment, and looking towards the future, do you think hardware (mobile and mainstream desktop) will continue to support your approach just as well, or are shader-based approaches (I guess using multi-channel SDFs) likely to gain the upper hand at some point?

The "traditional graphics pipeline" approach was chosen to maximise the platforms Rasterizer could run on, as GPU compute support at the time was patchy. Compute is now more universal, so Rasterizer could move that way.

SDFs are expensive to calculate, and have too many limitations to be practical for a general-purpose vector engine.

This project made me happy. You mentioned Flash as an inspiration. Have you looked at how Ruffle is handling vector art?

From what I recall they are converting it to triangles. Your solution (curves in the shaders?) seems both cheaper and more accurate, so I'm wondering if they could use it!

Ruffle is cool. From pixel inspecting the demo, it looks like they are using triangle fans with stencil & cover + MSAA, which was how I started!

Have you compared performance of your solution to rive?

No. I'm hoping someone else will do that ;-)

You mentioned winding numbers in a couple of places

Wouldn't it make sense to do a "first pass" and eliminate paths that intersect themselves? (by splitting them into 2+ paths)

I never understood why these are supported in the SVG spec.

It seems like a pathological case. Once self-intersecting paths are eliminated the problem gets simpler.. no?

Or would a CPU pass be cheating?

The Rasterizer algorithm handles self-intersecting paths without issue. Removing them requires expensive and complex computation geometry.

In a figure-8 path where the intersection is in the center of a pixel, does Rasterizer set that pixel to 0.5 or to 0?

Are there any culling optimizations for unseen elements when layering SVG images? Looks like this isn’t an optimization that comes out-of-the-box with OpenVG and all the major web browsers needed to add this, so wondering what your solution is doing.

The depth buffer is used for opaque path interiors.

Does that mean there’s no culling for overlapping elements? Sorry, just trying to understand your response.

How would you break down the problem with rendering 2D to someone who has no rendering background? Is there a single large issue or is it a complex multi-issue endeavour?

Winding numbers are easy to explain, but hard to compute efficiently: https://en.wikipedia.org/wiki/Winding_number

So what part of the SVG-spec does this implement? Does it support text? Gradients? Filters like blur and dropshadow?

None of that yet. The underlying SVG library, nanosvg, is very simple with no text support.

The first priority was to solve paths to pixels efficiently, including text (50,000 glyphs @ 60fps).

Gradients will be added when time allows, as I have code from a previous engine.

The coverage algorithm can be extended to support cheap box blurs, which could be used for drop shadows.

Ah ok cool! So what path to this being used in applications do you have in mind? Are you hoping to implement a decent part of the spec in the coming years? Do you have a rough timeline?

Rasterizer excels at animation and complex scenes, e.g. 2D CAD documents. The original inspiration was Flash, as I love innovative design tools. Flash 1.0 could easily be used by designers, but ultimately lost its way became a coder's toy after the Adobe acquisition and ActionScript 2.0.

Fleshing out the spec is planned, but I cannot provide a timeline as this has all been done at my own considerable expense. Maybe if my tips grow: https://paypal.me/mindbrix

Why did you release it only for personal use? Any chance for an OSI-approved license?

What magic makes the zooming work?

No magic, just 10+ years of experimentation and optimisation.