I've been working on this problem on and off for over 10 years. AMA ;-)
Have you compared performance of your solution to rive?
No. I'm hoping someone else will do that ;-)
Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
11–20 of 58 posts
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#12I am still endlessly fascinated by how modern GPUs can handle stuff like UE5, raytraced lumin (whatever) but still struggle to do 2D rendering. I mean I get it logically, but it just feels so disconnected.
Always neat to see this kind of stuff however. Very cool.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#13I've been working on this problem on and off for over 10 years. AMA ;-)
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?
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#14Congratulations! Can you say how the it's similar and how it's different to superficially similar sounding work? (1) https://github.com/linebender/vello , dual Apache/MIT, by Raph Levien et al (2) https://sluglibrary.com/ , proprietary, by Eric Lengyel (Terathon)
Slug is primarily designed for text rendering.
Vello is general purpose, like Rasterizer, but is based on GPU compute. Rasterizer uses the 'traditional' GPU pipeline. Performance numbers for both look very competitive, although Vello seems to have issues with GPU lock up at certain zoom scales. Rasterizer has been heavily tested with huge scenes at any scale.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#15I am still endlessly fascinated by how modern GPUs can handle stuff like UE5, raytraced lumin (whatever) but still struggle to do 2D rendering. I mean I get it logically, but it just feels so disconnected. Always neat to see this kind of stuff however. Very cool.
The core problem is path winding: https://en.wikipedia.org/wiki/Winding_number
Paths can be any size, and the problem is hard to parallelize. GPUs like stuff broken into small regular chunks.
TestFiles/Manchester_Union_Democrat_office_1877.svg is composed of a single huge path, which was a great torture test.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#16I've been working on this problem on and off for over 10 years. AMA ;-)
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
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#17I've been working on this problem on and off for over 10 years. AMA ;-)
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?
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#18Earlier quoted context omitted.
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?
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#19I've been working on this problem on and off for over 10 years. AMA ;-)
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 approac…
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.
Re: Rasterizer: A GPU-accelerated 2D vector graphics engine in ~4k LOC
#20I've been working on this problem on and off for over 10 years. AMA ;-)
What magic makes the zooming work?