resvg is an SVG rendering library.
resvg can be used as:
The core idea is to make a fast, small, portable, multiple-backend SVG library designed for edge-cases.
Another major difference from other SVG rendering libraries is that resvg does a lot of preprocessing before rendering. It converts an input SVG into a simplified one called Micro SVG and only then it begins rendering. So it's very easy to implement a new rendering backend. And you can also access Micro SVG as XML directly via usvg tool.
resvg is aiming to support only the static SVG subset; e.g. no
cursor elements, no events and no animations.
A list of unsupported features can be found here.
Results of the resvg test suite:
You can find a complete table of supported features here. It also includes alternative libraries.
Results of the static subset of the SVG test suite:
Comparing performance between different SVG rendering libraries is like comparing apples and oranges. Everyone has a very different set of supported features, implementation languages, build flags, etc. You should do the benchmarks by yourself, on your images.
resvg– rendering backends implementation
usvg– an SVG simplification tool
resvg-qt– minimal bindings to Qt
resvg-skia– minimal bindings to Skia
svgfilters– a collection of SVG filters
All other dependencies aren't written by me for this project.
benches- basic benchmarks for rendering operations
bindings– minimal bindings to Qt and Skia used by resvg
capi– C interface for resvg
docs– basic documentation
examples– usage examples for resvg as a library
src– source code
svg-tests- a collection of SVG files for testing
svgfilters- SVG filters implementation
testing-tools– scripts used for testing
tools– useful tools
usvg– an SVG simplification library used by resvg
- The library must not panic. Any panic should be considered a critical bug and should be reported. There are only a few methods that can produce a panic.
- The core library structure (see above) does not use any
unsafe, but since all backends are implemented via FFI, we are stuck with
usvguses unsafe for fonts memory mapping.
We are using regression testing to test resvg.
Basically, we will download a previous resvg version and check that the new one produces the same results (excluding the expected changes).
The downside of this method is that you need a network connection. On the other hand, we have 4 backends and each of them will produce slightly different results since there is no single correct 2D rendering technique. Bézier curves flattening, gradients rendering, bitmaps scaling, anti-aliasing - they are all backend-specific.
Not to mention the text rendering. We don't use the system fonts rendering, but a list of available, default fonts will still affect the results.
So a regression testing looks like the best choice between manual testing and overcomplicated automatic one. And before each release I'm testing all files manually anyway.
See testing-tools/regression/README.md for more details.
Also, the test files itself are located at the
resvg is licensed under the MPLv2.0.