Wikimedia wikis support uploading SVG files since 2005. At the time, web browsers had particularly poor support for rendering SVG. The ability to use SVG files in HTML/wiki pages (inline) was added by converting to bitmaps server-side. The rasterizer chosen for that was librsvg, which takes the SVG code and generates PNGs. librsvg was upgraded several times since and it has always remained Wikimedia's unique SVG rasterizer as of 2024 (see librsvg bugs for more history).
Despite the enormous progress achieved with these upgrades, rasterization with librsvg remains unreliable. The resulting bitmaps are frequently not faithful, as explained in librsvg bugs. And it is hard to blame that on upstream given how it describes its mission. From its README:
Goals of librsvg
Librsvg aims to be a low-footprint library for rendering SVG1.1 and SVG2 images. It is used primarily in the GNOME project to render SVG icons and vector images that appear on the desktop. It is also used in Wikimedia to render the SVG images that appear in Wikipedia, so that even old web browsers can display them. Many projects which casually need to render static SVG images use librsvg.
We aim to be a "render this SVG for me, quickly, and with a minimal API" kind of library.
Feature additions will be considered on a case-by-case basis.
You can read about librsvg's supported SVG and CSS features in the development guide.Non-goals of librsvg
We don't aim to:
Implement every single SVG feature that is in the spec.
Implement scripting or external access to the SVG's DOM.
Implement support for CSS-based animations (but if you can think of a nice API to do this, we would be glad to know!)
Replace the industrial-strength SVG rendering machinery in modern web browsers.
In short, librsvg was never designed for encyclopedic usage with arbitrary files, but one major reason why it was chosen is its performance. This aspect still matters today, since Wikimedia performs on average more than 200 rasterizations per minute (October 2024). As Gilles Dubuc explained:
The problem isn't as much the amount of SVGs we get per day, than the fact that we render thumbnails on demand when they're for a file/size combination never requested before. Any extra rendering time is a penalty for that viewer. The issue compounds if they request a lot of new thumbnails at once, making them more likely to run into throttling limits, resulting in erroring images. That can easily happen on galleries that get visited very rarely. But some people's workflows get them to visit those a lot and their overall experience becomes terrible.
We prerender the most common sizes at upload time, but there's a very long tail of more exotic thumbnail sizes requested because editors customised the sizes they wanted with wikitext, or the wiki itself has different defaults, etc.
thumbor's Grafana dashboard provides details about load in its Engines section. "qps" means "Queries per second".
During the 19 years since librsvg was chosen, other renderers have improved a lot, some even more than librsvg. 2 particular developments seem to allow reducing our reliance on librsvg and should be evaluated:
- The appearance of resvg, which would be the natural successor to librsvg insofar as it's also a free software performant server-side rasterizer written in Rust which implements a large part of SVG
- Browser support has become ubiquitous, and its quality is on par with librsvg.
resvg
resvg appeared in late 2017 and has quickly become a leader, thanks to tireless work by its creator, @RazrFalcon . Its major difference with librsvg is that it has a goal of supporting the whole SVG specification (although it concedes it has no plans to support animations). Tests run by @JoKalliauer in 2021 suggest resvg 0.14 had already surpassed librsvg at that time, both in quality and performance.
User agents
In principle, client-side rendering should be best, saving not only computation time but bandwidth, which should increase performance and quality while minimizing costs. All of the main browser engines (Blink, Gecko and WebKit) use their own renderer, but their quality appears to be comparable. Since they support animations, client-side rendering should be the preferred mechanism.
But one big concern is the variability of support between browser engines. For example, SVGator documents some differences with animation support. Allowing client-side rendering (basically) loses our ability to hack problematic files to ensure they are supported by the renderer.
This variability would however not be entirely new; when uploading an SVG file, the preview displayed is already rendered client-side, which can be particularly confusing when after confirmation the same browser then misdisplays the same file which librsvg doesn't properly render.
Transitional issues
Even if librsvg was deemed to offer 85% quality vs 90% for resvg, switching renderer needs careful consideration since the―say―10% files which resvg does not render well may contain files which librsvg renders well. With something in the order of 1 million SVG files on Wikimedia Commons, even regressions in 2% of cases could affect thousands of files. Keeping librsvg next to resvg to avoid regressions is a possibility, but identifying which files it handles better would be challenging. To switch confidently, we need to consider the impact on new files, on existing files, and anticipate how each renderer will evolve in the future.
Even evaluating a renderer's current quality is far from trivial. W3C's test suite was abandoned a long time ago, so that the most useful test suite appears to be resvg's as of 2024. This potentially biases our comparison.
Downsides of resvg
Unlike librsvg, resvg:
- is not in Debian (except for an excessively old version)
- is not a stock option for $wgSVGConverter
- does not claim to be ready (it remains at version 0 as of October 2024), but this should have limited impact on Wikimedia, since it reflects (up to now) constant API breaks, but Wikimedia. Yevhenii Reizner "would say that resvg is finished" as an SVG 1 renderer.
- still has no article on either the English or the French Wikipedia.
None of these are major problems, and they could be solved in the near future, but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future, decimating its chances of overcoming downstream inertia. The bus factor of librsvg (which was revived in 2016) appears to be a lot less bad than resvg's. resvg has a limited collaboration infrastructure and apparently no business model.
See Also
SVG test suites
SVG image support
T120746: Improve SVG rendering
T10901: [DO NOT USE] SVG rasterisation and management on Wikimedia sites (tracking)