Which resvg version was used for the benchmark comparison? Asking as librsvg 2.42.2 is from two years ago before it was ported to Rust. I'm curious how librsvg 2.46.4 (latest stable at this time) performs and compares.

@Aklapper resvg performance should be close, but it's basically impossible to compare. There are just too many differences and nuances.

As for supported SVG features, latest charts can be found here.

@Aklapper here the data from https://github.com/RazrFalcon/resvg#svg-support

I consinder the first coloum after programm (the w3c-Test Suite) as unbiased

PS: Currently we are running rsvg 2.40.20-3 on wikipedia servers

If you compare this table with T40010#4443760 you see resvg improved by 79 files, and rsvg only be 22 files, which indicates that resvg is not only better, but still develops faster.

For Performance we might need a commons test suite. (Performance is afaik depending on the test suite/hardware, and if the renderer does not know the feature you it rends it wrong, but faster, therefore maybe difficult to compare.)

Ping @fgiunchedi. Does this sound doable?

@JoKalliauer you can probably get root access on beta to do this yourself. @greg, is this right?

In T243893#5852761, @daniel wrote:

@JoKalliauer you can probably get root access on beta to do this yourself. @greg, is this right?

In theory, yes.

Will need a puppetmaster local patch to install the package. And a mw-config (deployed properly) patch to change the SVG renderer.

resvg only seems to be packaged in sid though, which is a bigger problem...

resvg only seems to be packaged in sid though, which is a bigger problem...

Yes, this is a problem with Rust projects in general. Latest librsvg isn't packaged in most distros too.

Untagging as trying out in Beta does not require an RFC discussion. This can be worked out between the proposer and anyone they might need help from in terms of Beta access. The local install and puppet.git cherry-picks can all be done independently, which is a nice aspect of how Beta works.

Note that if we're mainly interested in comparing SVG renderings, it might be easier to do that offline rather than already doing all the pre-production prep work for Beta Cluster. That way it only has to be installed for you locally and not in Beta Cluster. Any comparisons we want to do (e.g. pick 1000 most used or random SVGs from Commons, render side-by-side and generate SSIM scores perhaps?) can just as well be done locally, I think?

In any event, TechCom has no advice or opposition to this. Please report any conclusions about how well it works and/or any issues found on the RFC task at T40010.

The beta cluster still uses production Thumbor for thumbnail rendering. Testing resvg via MediaWiki on the Beta cluster would probably mean rendering all thumbnails via MediaWiki, or changes to Thumbor.

Testing this without MediaWiki or Thumbor in the way makes the most sense to me. Testing with a diversity of resolutions would also be important. In my experience, rsvg's bugs appear at lower resolutions (graphical errors) and at higher resolutions (rendering timeouts).

In T243893#5874557, @Krinkle wrote:

Note that if we're mainly interested in comparing SVG renderings, it might be easier to do that offline rather than already doing all the pre-production prep work for Beta Cluster. That way it only has to be installed for you locally and not in Beta Cluster. Any comparisons we want to do (e.g. pick 1000 most used or random SVGs from Commons, render side-by-side and generate SSIM scores perhaps?) can just as well be done locally, I think?

I compared resvg with rsvg, see T40010#5924909.
Basically there are negligible bugs in resvg, however the main problem in comparing is the files are optimized svgs for rsvg, leading to rsvg-bugs that are used as a feature see rsvg-Bug565, rsvg-Bug566, or rsvg-Bug567 (Bugs from the tested files).

So resvg would render them "correctly" according to the SVG-standard, leading to issues (if someone ?action=purge them), because the broken images must be fixed. However those broken files that use bugs as features, should get fixed anyhow, since Browser, Editors and feature releases of rsvg (even rsvg developes) will render them differently.

For new images is using bugs as features much less common than rsvg-bugs, therefore resvg will lead to less problems, also "we" will have to write Help-Pages such as Wikipedia:SVG_help new.