mindbrix
mindbrix on Hacker News
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!
The depth buffer is used for opaque path interiors.
My original target was iOS, so this was unavailable. I did experiment with their algorithm, but 4x MSAA was slow and had poor quality compared to Core Graphics, which was my reference.
My email address is in every file ;-)
Drawing cached renders in quads is how Core Animation works, but they do not scale well. You are ultimately limited by the CPU. Rasterizer enables a fully-animated canvas @ 60fps.
The longer answer is that using straight-edged geometry to represent curves is a resolution-dependent operation, e.g. a full screen circle may need to be flattened to an 80-sided polygon.
Rasterizer can solve quadratic curves in the fragment shaders, which massively reduces the geometry needed for a scene.
Also, the native rasterizer only supports MSAA, which is inferior to reference analytic area AA.
Good question and answer ;-)
My reference renderer has been Core Graphics. If it looks like CG I assume it's OK - and if it's not OK I'm in good company ;-)
You can switch between CG and Rasterizer in the demo app using the 0 key to see the difference for yourself.
Thanks, you imagine correctly ;-)
The current version uses Metal. I haven't even considered GPU ports yet, as my methodology is to get it working well on one platform first.
For single-pass SVG --> texture, a CPU approach would probably offer the lowest latency. For repeat passes, the GPU would probably win.
Thanks. I couldn't really say without doing proper research.
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
The Rasterizer algorithm handles self-intersecting paths without issue. Removing them requires expensive and complex computation geometry.
I can't really answer that in detail yet. I suspect Rasterizer will be faster for complex scenes.
No magic, just 10+ years of experimentation and optimisation.
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.
The core problem is path winding:
https://en.wikipedia.org/wiki/Winding_numberPaths 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.
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.
No. I'm hoping someone else will do that ;-)
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.
Hi Steve. Yes, it is! 10+ years in the making.
Thanks for the feedback. I will work on one.
I've been working on this problem on and off for over 10 years.
AMA ;-)
Posted by
mindbrix on Monday September 01, 2025 @03:56AM
from the github.com dept.
The WebGL antialiasing quality looks poor compared to the software renderer. It could be using MSAA instead of full analytical AA.
I had to use Chrome to test it, as the viewer doesn't play on Safari.
https://thorvg.github.io/thorvg.viewer/
Posted by
mindbrix on Monday March 16, 2020 @07:38AM
from the twitter.com dept.