Page MenuHomePhabricator

Test resvg on Beta Cluster
Open, Needs TriagePublic

Description

According to T40010 resvg seems to be a realistic alternative to rsvg, it is faster and should support more features, such as T11420 T36947 T20463 T35245 T32033 ,... (see T40010#4443760 )

Benchmark of https://www.w3.org/Graphics/SVG/Test/20110816/

Programrender timeTests passed
resvg150 s (best)280 (best)
rsvg 2.42.2242 s202 (worst)
Inkscape 0.92.41610 s249
Batik 1.123686 s269

According to Commons:Village_pump/Proposals I got the suggestion/support to test resvg on https://commons.wikimedia.beta.wmflabs.org

Event Timeline

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

Programhttps://www.w3.org/Graphics/SVG/Test/20110816/https://github.com/RazrFalcon/resvg-test-suite
resvg 0.9.0280 (best)1261
rsvg 2.47.2224 (worst)979
Inkscape 0.92.4249955
Batik 1.12269933

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?

daniel added a subscriber: greg.Feb 5 2020, 4:38 PM

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

Reedy added a subscriber: Reedy.Feb 5 2020, 4:48 PM

@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.

Krinkle renamed this task from Test resvg on beta-cluster to Test resvg on Beta Cluster.Feb 11 2020, 10:30 PM

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.

Ebe123 added a subscriber: Ebe123.Feb 13 2020, 3:01 AM

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).