Skip to main content


I really want to port Cairo's internals to Rust.

It is going to take a fuckload of refactoring to make it unit-testable, anyway.

However, I don't yet know if it is worth it.

Is there an alternative to Cairo for projects that really use it to draw 2D stuff? Including librsvg? People tell me that Skia is not it, but I am eyeing tiny-skia as a Rust alternative for librsvg.

in reply to Federico Mena Quintero

I personally learned more about good C library design from briefly working on cairo than I did from any other single project, so I always hope for the best for that code base. I don't know what's happened in the two decades since then though
in reply to Jamey Sharp

@jamey Oh, yeah, in terms of how to design a library it is really good. Awesome by C library standards.

I think Cairo's main flaws are its testsuite that does not pass by default, the undocumented internals - specialist code, and the lack of unit tests.

in reply to Federico Mena Quintero

sounds like fixing the testsuite is the prerequisite 😞 Wouldn't dare do any refactoring without that (and unit tests). Good luck !
in reply to Edward Hervey

@bilboed @jamey Already tried fixing the test suite twice. Maybe I should try it again 😄

But yeah, what I want to fix is very low-level, and there are practically no tests for the low-level bits ("do all the code paths in cairo-polygon get tested?"). Most of the test suite uses the public API, either to compare renders to reference images, or to try to exercise certain tricky code paths.

So I'm going to do the #ifdef TEST dance in the main sources and see if the maintainers like that.

in reply to Federico Mena Quintero

@bilboed Is there any fuzzing infrastructure for cairo yet? I'd expect OSS-Fuzz would contribute CPU time for continuous fuzzing of cairo, like they do for lots of other infrastructure projects… and coverage-guided fuzzing tends to be a remarkably quick way to, well, increase coverage.
in reply to Jamey Sharp

@jamey @bilboed Cairo *is* in oss-fuzz; the container images don't build - introspector.oss-fuzz.com/proj…

I haven't gotten there yet, and I don't know what the fuzz targets look like.

in reply to Federico Mena Quintero

@bilboed Not testing much and they look full of bugs too, I think. Oof. I wonder if "Google-Autofuzz" was an attempt at using some kind of early LLM-like thing to generate fuzz targets…? Well, it seems to me like you could get a long way by treating the fuzz input as SVG and feeding it to cairo via librsvg.
in reply to Jamey Sharp

@jamey @bilboed Right now the librsvg fuzzing stuff (and by extension Cairo's) is stuck in the crashes in Cairo's path renderer. You feed it coordinates that are outside of cairo_fixed_t's representable range, or close to its bounds, and it crashes.

Unfortunately the SVG-based fuzzer has not yet gotten to the point where e.g. it generates a crazy clipping path for something else. Too much syntax to get right :)

(Cairo needs more fuzz targets, and testable algorithms - I'm on the latter.)

in reply to Federico Mena Quintero

cairo's meson now, so sneaking in some std-only rust should even be fairly easy tooling-wise these days 🙈

Doubt it'd win us many friends though :/

in reply to zbrown

@zbrown hehe, already fought that fight with the non-friends once, in librsvg, and it was mostly fine through aggresive ignoring of people who are not putting effort into the codebase :blobcatangel:
in reply to Federico Mena Quintero

yeah I guess I'm just wondering who the Cairo userbase may include on top of those rsvg users
in reply to zbrown

@zbrown Probably people who can already compile librsvg, otherwise they can't compile the Cairo test suite 😃 😃 😃

More seriously, I'd love for someone to RTFS and write up how a variety of apps or libraries use Cairo directly. Do they Really Draw Interesting Stuff(tm) or is it something that they could do easily with e.g. GTK these days? How much work would it be to do that instead?

in reply to Federico Mena Quintero

aha, didn't realise it was mildly circular like that, interesting.

That'd be quite the project, and at least in the context of gtk apps I wouldn't be surprised if a lot of it could even be CSS by now.

in reply to zbrown

@zbrown I *think* distros tend to disable the SVG-based tests to avoid that circular dependency. Librsvg is not used in the library code, just in Cairo's test suite.
in reply to Sebastian Wick

@swick I'm looking at all that stack from a distance. It's a very cool research project where I cannot find the tests or documentation on the internals :)
in reply to Federico Mena Quintero

I'd rather say it's the product of previous research projects :)

It certainly isn't as mature as cairo or even skia but I do believe that it's the one thing that will dethrone cairo eventually. But who knows, I don't have a crystal ball...

in reply to Sebastian Wick

@swick Oh, I mean, I wish them the best. It's very cool work.

But if you are an existing user of Cairo...

* Can you port your (certainly underfunded) app away from Cairo?
* Can you even use a GPU renderer without massive rearchitecting?
* Do you use pango/cairo for text? Can you switch to the lower-level layers, or something else?

in reply to Federico Mena Quintero

good questions. at least the API is supposed to be cairo-like. for the rest I don't have answers.