
Helping Cairo, the rendering library - buovjaga
https://people.gnome.org/~federico/blog/helping-cairo.html
======
dmm
> But some tests, I have no idea what changed that made them break.

Michael Feathers in "Working Effectively with Legacy Code" defines a unit test
as a test with two qualities:

1\. It runs fast (1ms is slow for a unit test) 2\. Has excellent locality, so
when a test fails it's obvious what code broke it

From my experience fixing sparc64 package builds for Debian the second quality
is hard to get right. Many times I would encounter a test failure that was the
result of a complicated chain of function calls and it wasn't obvious what was
broken.

When I was fixing the gtk build I discovered their codebase is sprinkled with
ASSERTs which turned out to be SUPER useful, particularly because they
communicated exactly where a precondition wasn't holding up. Previously I was
never that interested in asserts but that experience makes me want to look
into them again.

~~~
makmanalp
On the flipside the reason excellent locality usually doesn't happen is that
the narrower the scope of your tests are (think on the spectrum of integration
tests to unit tests), the likelier that they are highly coupled with
implementation details that might change, making tests brittle and refactoring
harder. Or you go the full java style strategy-pattern-dependency-injection-
abstractsingletonproxyfactorybean route to get both locality and ease of
changing behavior, but then you're now building these complex class
hierarchies and doing anything takes a lot more effort and boilerplate. Now
changing behavior is easy but changing architecture is hard. It's a tough
tradeoff, really. I'm not saying we don't need one or the other, but it's more
of a case by case judgement call that folks would like to admit IMHO.

------
kjksf
Unfortunate reality is that Cairo project doesn't want to be helped.

I've been checking Cairo from time to time for a very long time. There was a
period of active development because it was used by FireFox and, I think, had
at least one dev working on it paid by Intel.

But there's no indication that the project wants your help. See
[https://www.cairographics.org/](https://www.cairographics.org/) and try to
find the part that tells you how to submit a patch. To submit a bug you need
to use a mailing list or antiquated bugzilla instance.

Cairo is ostensibly a Gnome-affiliated project as it's used in Gtk. Federico
is a big deal in Gnome project.

It's telling that he had to setup up essentially a personal fork of Cairo on
gitlab to do any work.

At this point in time, moving the code officially to GitHub (or GitLab) from
anongit.freedesktop.org should be a no brainer if your goal is to have
contributors.

~~~
seibelj
A lot of open source projects don't want to be helped, given how hard it is to
contribute. I've submitted a few patches to various projects, closing open
issues, that still linger as PR's years later.

~~~
pryelluw
Or are not able to receive the help in some way. This is mostly a people issue
and not everyone is able to manage people effectively.

------
stuaxo
Cairo is a library that has a great balance between the simplicity of it's
abstractions and the power it gives you.

Christoph Reiter has been doing some great work to revive and update the
python bindings.

[https://github.com/pygobject/pycairo/](https://github.com/pygobject/pycairo/)

I'd also like to point out Cairo generally has a friendly mailinglist, and is
quite a fun library to make graphics with.

------
ksherlock
The proposed c++ 2d graphics standard is based on Cairo.

[http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7....](http://open-
std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7.pdf)

"The reference implementation of this paper provides a software implementation
of the math and rendering support classes. This is based on the Cairo library;
indeed, so far the reference implementation has been based on Cairo. However,
it is now possible to provide an implementation more appropriate to the target
platform."

~~~
sparkie
I think the committee will (and should) throw this proposal out of the window.
Most of the notable C++ projects are already using Skia.

------
speps
The problem with Cairo is that it's painfully slow. Last time I tried, I don't
remember what it was exactly but it just couldn't cope with realtime
performance.

~~~
awalton
> The problem with Cairo is that it's painfully slow.

It really isn't though... it's just painfully easy to fall onto slow paths,
and not obvious how _not_ to. Time and again I've seen people stack benchmarks
of cairo where they're only benchmarking the image surface; of course that's
slow, it's CPU rendering! If your realtime graphics app is ever creating a new
surface and it's _not_ using cairo_surface_create_similar() or
cairo_{xlib,xcb}_surface_create(), you've probably fucked up.

Nearly 100% of the time, when someone's fallen into a slow path using cairo,
it's because they've managed to get cairo to copy something back from the
graphics server, do some operations on the CPU, and then reupload back to the
server. And surprise, that's _very slow_. After that, the majority of
remaining slow cases are due to creating too many clipping regions (which is
common in lots of complex rendering applications, but usually caught by the
application developers themselves since Cairo's actually remarkably good at
debugging these kinds of rendering issues with tools like the script surface
and cairo-perf-trace).

Meanwhile, Firefox has managed to pretty much stamp out all of the rest of the
actual painfully slow Cairo paths...

Part of this perceived slowness in Cairo is because the example code is pretty
bleak and abysmal (just look at
[https://www.cairographics.org/documentation/](https://www.cairographics.org/documentation/)
if you don't believe me), part of it is because everyone who used to maintain
cairo (before they ran off and are now doing VR at Valve, or Wayland, or
Tizen, or whatever) were Xorg developers and Xorg things were "so trivially
obvious" to them that _isn 't_ trivially obvious to... basically everyone
else, and part of it is because of "stack-overflow-itis" \- "I'm just going to
copy this example code because this guy got it working and I don't care to
understand the mechanics of how/why it works/why it's slow in my code."

tl;dr: cairo's not slow, stop creating/rendering against image surfaces, use
the perf tools to keep clear of bad application behaviors.

~~~
yetihehe
Yeah, I was actually surprised at how fast cairo can be. I had some ideas as
to optimize things like prerender map markers into some tiles and then render
those tiles, but it seems for my use case (rendering less than 10k small
images on single surface) I didn't even need to optimise it, with 2k images I
had over 40fps which felt more snappy than google maps, which was enough. Of
course if someone needs something better, hw accelerated opengl is the way to
go. Current processors are fast, but they have their limits.

~~~
hawski
There is cairo-gl. AFAIR it's still considered experimental, but good enough.
I did not try it yet.

