<div dir="ltr">Hi all; I have breached this topic on a couple of IRC channels, but I wanted to open the floor for discussion on the Cairo mailing list, in order to reach out to the larger Cairo community. After the last discussion[0] on this list about the state of the maintenance of Cairo, I decided to have a look at the current development branch and see what we can do about it. Background: I am currently working for the GNOME Foundation as a GTK developer. I have been part of the GNOME community for the past 15+ years, and maintain a few libraries and low level dependencies of GTK, like: - [libepoxy](<a href="https://github.com/anholt/libepoxy">https://github.com/anholt/libepoxy</a>) - [gdk-pixbuf](<a href="https://gitlab.gnome.org/GNOME/gdk-pixbuf">https://gitlab.gnome.org/GNOME/gdk-pixbuf</a>) - [graphene](<a href="https://github.com/ebassi/graphene">https://github.com/ebassi/graphene</a>) I have taken over the first two after they stopped being maintained, and worked on getting them to a clean, releasable state. While I have been using Cairo for more than a decade, I have never been involved in its development. For the past 5 years, the GTK developers have actually been working on reducing the use of Cairo inside GTK, towards the use of GL (and Vulkan) as the main drawing API for the toolkit. Nevertheless, while GTK4 tries very hard *not* to use Cairo in its default code paths, we do fall back to it whenever GL is not available; on top of that, we still expose some Cairo types in our API, and we still use Cairo as the default backend for text rendering and printing. While that might change in the future, we are still three to four years away from that, and we'd still have to maintain our extant code and API for a few more years after that. From the perspective of GTK, the current state of maintenance of Cairo is problematic at best. We'd like to add API and functionality to it, but the lack of response for those changes makes iterating and fixing issues very complicated; we are, after all, stretched too thin ourselves. Not knowing if a change will effectively land, or be part of a release, naturally leads to workarounds; downstream distributors end up either shipping snapshots of Cairo, or we end up with issue reports because we have to depend on unstable features. This inevitably leads to friction between end users, distributors, and maintainers, and instead of working together we end up trying to route around one another. This is an untenable situation for everyone. Ideally, I'd like to help with the maintenance of Cairo. I am not an expert in the tesselation code, or in font rendering, or in the image scaling code; but I can deal with making releases, keeping the CI running, automating the website maintenance, triaging issues, and fixing the build. More importantly, since Cairo is still a GTK dependency, I can spend my work time on those tasks. Of course, since this might look too good to be true: my offer comes with strings attached, and this is where things might get controversial. First of all: Cairo is full of conditionally built code that is barely maintained, and seldom enabled. This makes maintenance more complicated because nobody is really exercising the whole code base except for some long tail end user. Cairo has too many science experiments, and too many small fiefdoms, and not enough people that care about the whole project. People end up enabling some random feature without realising that it's a trap; downstream packagers don't really know what to enable at compile time, either. For this reason, I'd like to whittle down the size of the code base. The following backends would need to go: - OS/2 - BeOS - Qt - DRM - GL (GLES, EGL, GLX, WGL) - Cogl - DirectFB - XML The supported backends would be: - image - recording - Xlib - XCB - Win32 - Quartz [1] - Tee [2] - SVG - PDF - PS This is, essentially, the currently exercised subset of Cairo that GTK needs in order to work, plus the requirements of other users of Cairo according to Debian's code search. I'd like to be able to say: "if you want to keep a backend alive, please show up and maintain it", but the truth is: none of the backends I'd like to remove are really used by anything that is currently relevant outside of a moderately long tail of niche users. If you rely on custom builds for your project/product, I'm sure you can also continue using Cairo 1.16. I'd be happy to backport all the relevant changes to the 1.16 branch, before sealing it for good. Additionally, I would drop the Autotools build from the repository, and rely entirely on Meson. Maintaining two build systems is not anybody's idea of "fun", and the extant Autotools build is basically running on cargo culting alone. Meson has proved itself to be a reliable build environment, especially after GNOME, Mesa, and the X.org projects have switched to it. Of course, the Meson build needs some additional fixes, like: - a better test suite integration, to enable parallelism and per-backend options - porting some of the existing tests currently written as shell scripts, and vetting their usefulness With the Autotools build gone, it's possible to avoid targeting the minimum common denominator, and ensure that Cairo can build properly on multiple platforms. GTK currently builds Cairo as a Meson sub-project on Windows (with the MSVC toolchain) and macOS, which gives us a functional baseline. I have started these changes in a separate branch, called "Tanis"[3] available on GitLab: <a href="https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis">https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis</a> Some of the commits there are fairly uncontroversial, and deal with fixing compiler warnings or other small build issues. The commits prefixed with "tanis" are the ones that I feel are going to be more controversial. As I said above, I am not really involved with the development of Cairo; I am just a downstream consumer of it. The larger Cairo community might not be enthused by somebody dropping by and asking to assume the role of release manager with a laundry list of changes that drop code and features. I *do* empathise with that, and I'm entirely prepared to a "get lost" reply. Sadly, it seems that the other option is keeping Cairo on life support, landing changes but never really releasing them; since there are still downstream users of Cairo, and those projects do have quite some traction in the larger free and open source ecosystem, either those projects will accelerate dropping Cairo, or will be forced to perform a soft fork, with an ABI compatible release from a separate branch or repository. Neither of those solutions would be acceptable to me, and I'm sure multiple downstreams would also find it very hard to swallow. So, I guess my question is: would this plan be acceptable to the people still involved with the development of Cairo? If it is, I'd be happy to work on: - merging the Tanis branch - cleaning up the documentation, and updating it to the current status - refactoring the test suite so that it can properly run on the CI pipeline - going through the API reference and ensuring that it's up to date and correct - fixing the cairo-www repository, and using GitLab pages for publishing the content - doing a new development snapshot Ciao, Emmanuele. [0]: <a href="https://lists.freedesktop.org/archives/cairo/2020-November/029080.html">https://lists.freedesktop.org/archives/cairo/2020-November/029080.html</a> [1]: Provisionally; the performance of the Quartz backend on modern macOS has degraded to such a point that it's literally faster to draw on image surfaces. [2]: I have checked on the Debian code search, and while the Tee backend is still in use for Firefox, I'd also consider dropping it given its experimental nature. [3]: an old capital of the ancient kingdom of Egypt; and, of course, the fictional resting place of the Ark of the Covenant in "Raiders of the Lost Ark". -- <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a> [@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>]</div></div>