It seems the only alternative is Skia (https://skia.org/), which is a Google project…

AFAIK one issue with Skia is that its API is not stable (and it is written in C++ which makes stability kinda hard) whereas Cairo's API has been stable for a long time.

Side note: Skia can't render SVGs directly. You need a separate library to do the parsing and issue commands to Skia. I think they might have experimental support for simple svgs committed in the repo, though.

great, so it has what 18 months before being killed off?

Skia has been around for 15 years (open source for 12) and is used in a number of high priority projects for Google (e.g. Android, Chrome). It's incredibly unlikely it will be killed any time soon.

It's used by Chrome, Blink, and a lot of other projects, so unlikely to be killed any time soon.

resvg - https://github.com/RazrFalcon/resvg

The developer also produced an incredibly useful SVG test suite comparing various libraries https://razrfalcon.github.io/resvg-test-suite/svg-support-ta...

Blend2d - https://blend2d.com/

Blend2d is still slower than skia. The only renderer that I know that could outperform skia is fastuidraw

Can you post a link to any benchmark that would prove that?

https://blend2d.com/performance.html The official benchmarcks show that blend2d isn't significantly faster than QT or Cairo renderers and it is common wisdom that Skia often order of magnitudes faster than them. I talked to the blend2d author ~ a year ago and he will not publish skia benchmarck until it's new "more parallel" version of blend2d is ready which imply he is skeptic that current blend2d is competitive with Skia.

Fastuidraw is the only renderer to have shown benchmarcks outperforming skia but it is mostly unmaintainef today and the benchmarks weren't representative

Do you think it's right to state something because of "common wisdom"? Claims like "order of magnitudes faster" should be supported by a reference, because from my own experience making something order of magnitude faster is really difficult and sometimes impossible. This is btw why Blend2D provides a benchmarking tool, to not claim something that cannot be verified.

I'm the author of Blend2D and I have never stated what you claim I did. I just gave up trying to compile SKIA. The benchmarking tool Blend2D uses is open source, maybe you can contribute SKIA backend to the tool and use it as an evidence? Otherwise all you say is just unfounded, sorry.

BTW SKIA team was positively impressed by the performance of Blend2D when it came out and we are in contact. I would not be surprised if SKIA started using similar techniques like Blend2D - for example JIT compiler. They are exploring new territories like Blend2D does.

Interesting!

OK so it's not common wisdom but expert wisdom: Quoting Pcwalton (working on a next generation 2D renderer: pathfinder) How do Skia and Cairo compare? Skia is way ahead in terms of performance and GPU support.

A lot of major projects like Firefox and libreoffice switched from Cairo to Skia and got significant performance gains. How much faster in average is skia vs Cairo? A lot but precisely I don't know and it doesn't matter much.

I just gave up trying to compile SKIA. Come on, don't make it sound like it's a hard task, on the github issue from blend2d someone gave to you a repository that include a Cmake for skia which should be straight-forward.

Claim: he will not publish skia benchmarck until it's new "more parallel" version of blend2d is ready which imply he is skeptic that current blend2d is competitive with Skia.

Claim denial: I'm the author of Blend2D and I have never stated what you claim I did.

What you actually said: I think comparing with GPU implementations would make sense after multithreaded renderer lands, because competing GPU implementations use the whole GPU hardware whereas the current Blend2D software-based renderer only uses a single thread. Would make sense easily translate to I'm not interested in doing it until there is a point in doing it which is: a fair comparison. Source: https://github.com/blend2d/blend2d/issues/36

Otherwise all you say is just unfounded, sorry. Original statement: Blend2d is still slower than skia Backed by expert wisdom comparing skia with cairo showing huge performance gap. Blend2d own benchmarcks not having a that huge performance gap with cairo (but it has kinda with the multithreaded mode I give you that) Then the logical reasoning become basic transitivity/equivalence relation To state that what I said is unfounded is a low effort refutation because it is too categorical. In all honesty my reasoning has weakness: I don't have precise quantification of the lead that Skia has over cairo (maybe there was some benchs on the NVpath paper?) and multithreaded blend2d do have a quite significant gap with cairo. So optimistically, current blend2d might actually come into the ballpark of Skia, it could even outperform it but probably not by a huge margin. And keep in my that the baseline performance I expect from skia (very old benchmarcks and expert wisdom based on old benchmarcks) has probably improved since recent years (e.g one could think about more AVX512 use, the Vulkan backend, etc)

So I'll transform my original statement in an equivalent one consequence wise: Blend2d is still slower than skia to: Blend2d has not shown evidence of being faster than skia, nobody should use it until this evidence become available.

I'm not going to contribute, sorry. Your last paragraph is interesting and that would be quite of an achievement of you if Skia tried a JIT compiler.

Ok, so you cannot prove it, which means that I must prove otherwise?

I wrote exactly what you cited in May 2019, but it was not about SKIA. And if you continued reading you would have noticed that multi-threaded rendering context implementation is already provided. So, I don't really understand what is your point here.

There are Blend2D users that started using the library based on their own benchmarks that compared Blend2D, SKIA, and also AGG. So there are already users that use Blend2D instead of SKIA based on their own benchmarks, and I think that's a much saner approach than following your "expert wisdom".

What about Skia?

Apparently hard to build.

It's not the most fun project to build, but not that hard following the directions here: https://skia.org/user/build.

I've even been able to get it to build on a Pi (although that took more elbow-grease).

Also, if you're using Rust, the rust-skia [0] project provides prebuilt binaries for a bunch of platforms and using it is as simple as putting it in your Cargo.toml.

[0] https://github.com/rust-skia/rust-skia

It used to be really hard, though I believe there's now experimental cmake support. Vcpkg has it, so if you're using that, it's much easier.

librsvg ?

librsvg uses cairo under the hood to actually draw things, at least at the moment.

Argh! Package dependency hell of the second kind: mandatory requirements. It could be A Good Thing™ parts are being rewritten in Rust, but the costs, performance, and modularity of maintaining vs. ditching cairo needs to be weighed. Having two SVG rendering engines would have advantages (choices) and disadvantages (compatibility, security, code bloat).