Blend2D – 2D Vector Graphics Engine

Blend2D – 2D Vector Graphics Engine(blend2d.com)

159 points by philix001 7 years ago | 41 comments

w0utert 7 years ago |

Very interesting and useful, but when I read the title I was hoping it would be something different.

I would love to find some kind of stripped-down vector graphics engine that is fully geared towards real-time rendering of path-based graphics for games. For example to write retro-style games that use 2D vector graphics instead of textured quads. I've been writing a simple game that uses this graphics style, and so far I've been simply using pre-rendered textures for sprites. Being able to directly render these things by composing vector-based layers would allow all kinds of interesting effects and image quality improvements, e.g. seamless scaling morphing, etc. Obviously this would be way, way slower than emulating these things using bitmap textures and/or SDF's for scaling, but for the simple graphics my game is using that should probably be fine, even on mid-range hardware there is plenty of frame time I could dedicate to vector rendering and still hit at least 30fps.

logicalshift 7 years ago | |

There are a few of those out there. Nanovg seems to be the one that fits your requirements most closely. If you're into Rust, lyon (plus something like gfx-rs) is another choice.

It's also worth noting that the HTML canvas implementations in most browsers is also not too bad for performance. Quartz is also really fast, but Apple made it really easy to accidentally use a slow rendering path (especially for bitmap operations)

underst0rm 7 years ago | |

I have had great success using the ideas presented here (http://m1el.github.io/woscope-how/index.html) for simulation of traditional vector graphic screens. It is very fast and easily modified to allow for intensity modulation as well.

schaefer 7 years ago | | |

I really enjoyed your demo. Thank you.

AriaMinaei 7 years ago | |

Pathfinder fits the description: https://github.com/pcwalton/pathfinder

This AR demo on MagicLeap shows the potential: https://twitter.com/asajeffrey/status/1106667615622180864

Jasper_ 7 years ago | |

GPUs really just aren't designed for 2D vector graphics. There is a litany of approaches (three separate ones from pcwalton's Pathfinder R&D alone), and all of them have various issues and tradeoffs. If your GPU has enough power for one of the more advanced approaches like Slug or Pathfinder1's compute shaders, then your CPU likely has enough for Blend2D and the bandwidth for the resulting texture upload.

Pathfinder3 looks promising, but comes with its own tradeoffs. It's an open area of research.

raphlinus 7 years ago | | |

When listing approaches, people should look at Skia Compute[0]. While it is true that traditional GPU's are not a super-great match for 2D graphics, modern GPU's are becoming more and more CPU-like, just with more parallelism. I haven't done careful quantitative evaluation of compute myself, but don't feel that any understanding of modern 2D graphics performance would be complete without that.

[0]: https://github.com/google/skia/tree/master/src/compute/skc

c-smile 7 years ago |

If to speak about UI needs then CPU rasterization is just half of the problem.

320 PPI display (a.k.a. "Retina") has 9 times more pixels than old, classic 96 PPI one.

So just attaching new monitor will require 10 times better CPU in order to render the same UI. That if to use CPU rasterizers only.

Obviously that above is not an option. That's why Direct2D and Skia contain as GPU as CPU rasterizers. That dualism complicates things quite a lot - two alternative renderers under the same API roof shall produce similar results.

So Blend2D, to be a viable solution for the UI, shall be 10 faster in rasterizing than any current alternatives.

Yet, it was NV_path_rendering OpenGL extension from NVIDIA aimed for 2D path rasterization, but it seems the effort is dimmed now as OpenGL itself. OpenGL architecture, that was created to run H/W accelerated full screen apps, is far from being adequate for windowed UI.

So far Microsoft's Direct2D is the best thing that we have for H/W accelerated UI so far. And WARP mode in Direct2D (CPU rasterizer) is pretty close to the Blend2D - they also use JIT for rasterizing AFAIK.

IshKebab 7 years ago |

This is such a well-made landing page. Tells me what it does, what makes it good, isn't full of vague marketing waffle, doesn't put one sentence per screen, and has actual code and output examples!

royjacobs 7 years ago |

This is very interesting. Especially since other vector engines are either unmaintained (like Antigrain) or extremely hard to build (Skia, Cairo).

I do wonder if these kind of libraries shouldn't be supplanted by hardware accelerated rendering, though.

pettou 7 years ago |

I'm eagerly following the project for several years now, very well done Petr and Fabian!

Asm2D 7 years ago | |

Really appreciated, thank you!

raphlinus 7 years ago |

How does the performance of path filling compare to font-rs?

Asm2D 7 years ago | |

Blend2D uses dense cell-buffer similarly to font-rs, however, it works quite differently and this difference allows Blend2D to be efficient even when rendering large paths:

- Dense cell buffer, 32-bit integer per one cell (FreeType/Qt use sparse cell buffer and two 32-bit integers per cell, font-rs uses float if I'm not mistaken)

- Blend2D builds edges before rasterization step, edge builder is optimized and performs clipping and curve flattening

- Rasterization and composition happens in bands, thus storage required by the cell buffer is quite small (currently band is 32 scanlines, but we will make it adjustable based on width)

- To complement dense cell buffer Blend2D uses also a shadow bit-buffer to mark cells that were altered by the rasterizer

- Compositor scans bit-buffer instead of cell-buffer to quickly skip areas that were not touched by the rasterizer

- Compositor is SIMD optimized and calculates multiple masks at the same time (at the moment it works at 4 pixels at a time, but this can be extended easily to 8 and 16 pixels)

- Compositor clears both cell-buffer and shadow bit-buffer during composition so when the compositor finishes these buffers are zeroed and ready for another band

- Blend2D maintains small zeroed memory pool that is used to quickly allocate cell and bit buffers when you create the rendering context and returned to the pool when you destroy it

There are probably more differences, like parametrization of NonZero and EvenOdd fill rules, etc, but these are really implementation details to minimize the number of pipelines generated by common rendering operations.

The advantage of font-rs is rendering small paths, large paths will have increasing overhead as a lot of computations would happen on zero cells. Blend2D rasterizer is universal and was tuned to perform well from small to 4K framebuffers.

When I was designing Blend2D's rasterizer I wrote around 20 rasterizers and benchmarked them against each other in various resolutions. I had similar rasterizers like font-rs (but not using floats) and these were only competing in very small resolutions like 8x8 and 16x16 pixels. When shifting to larger resolutions these rasterizers would always lose as shadow bit-buffer scan is much quicker than going through zero cells, especially if you do pixel compositing.

There are demo samples in bl-samples-qt repository that render animated content and have Blend2D and Qt rendering options. You can check them out to see how the rasterizer competes against Qt.

Let me know if that answers your question.

vanderZwan 7 years ago |

Whenever SVG rendering engines come up, sooner or later the question of "which part of the SVG spec does it render incorrectly?" comes up. How does this one fare?

I get the impression that often these rendering bugs are partially caused by old optimizations that break later spec changes or missed some edge cases the first time around, so I hope that means this engine does better than most because it's more recent, built from-the-ground-up and can learn from the mistakes of others.

mfabbri77 7 years ago | |

Blend2D isn't a SVG rendering engine; maybe a SVG rendering engine can be built on top of Blend2D. But anyway SVG specifications are a hell (and these include a lot of features that are not related to the pure rendering). How do i know? I'm one of the developers of https://www.amanithsvg.com

Pxtl 7 years ago | |

Things like this convince me more and more that SVG is overdesigned and solving the wrong problem:

The world needed a vector version of PNG far more than it needed a vector version of HTML/CSS.

gardaani 7 years ago | | |

W3C is creating a subset of SVG called "SVG Native". It is intended for icons and simple graphics, so it won't have support for text, scripts, links or XSL processing. Also, use of CSS or animations isn't recommended. It will be similar to SVG in OpenType fonts: https://docs.microsoft.com/en-us/typography/opentype/spec/sv...

microcolonel 7 years ago | | |

I will push back a bit and say SVG's integration with HTML documents is very convenient and useful. I think it has been held back by poor implementation, particularly Mozilla's.

The SMIL stuff has made the SVG DOM a bloody mess, and it's deprecated everywhere, which is a sad outcome, but it's still useful.

bitbang 7 years ago | | |

That makes no sense. SVG _is_ the vector equivalent of PNG. Just because it's defined in an xml namespace that can be directly embedded in html, doesn't mean it is somehow bound to it.

mfabbri77 7 years ago | | |

Definitively, this.