Live data from Hacker News

Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

github.com

51–58 of 58 posts

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#51
post #28

Earlier quoted context omitted.

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?

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#52

Maybe its me and I am more than okay but I went into a whole license rabbit hole trying to figure out the license that it uses It uses this "personal use zlib license" And So earlier it was actually licensed under the zlib license which I think of as in something similar to the MIT license (I think, I am not a lawyer) My issue with this is that the personal use zlib license to me feels like its made up by the author,…

Yes, ad-hoc licenses are a big red flag. What counts as "personal use"? Does that mean "non-commercial", or that you can only use it for yourself and cannot distribute software made with it? If someone distributes free open source software, would that count as personal use? Or would the end-users of that software be restricted from using it for whatever counts as non-personal-use due to this dependency?

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#53
post #2

I've been working on this problem on and off for over 10 years. AMA ;-)

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.

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#54
post #2

I've been working on this problem on and off for over 10 years. AMA ;-)

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.

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#55
Sorry to be blunt, that C/C++ code is crustyyy. Just to start with run this through an decently complete clang-tidy profile and fix all errors and warnings. That should become part of your build. The longer you hold out on that the harder it will be. Your code has no provisions to handle fuzzed/corrupted content. Maybe a better idea would be to switch this entire code base over to Rust.

Consider modern C++ practices as outlined here: https://github.com/cpp-best-practices/cppbestpractices/blob/...

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#56

Earlier quoted context omitted.

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.

Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC

#57
post #43
post #2

I've been working on this problem on and off for over 10 years. AMA ;-)

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!
Post reply on HN