Can we talk about why projects need to be actively maintained and extended indefinitely? Cairo paints things. It does a good job of it. What's wrong with it? Leave it on Git, accept pull requests, check it once a week/month, you're good.
Examples of things you would need to have added in the past few years to stay competitive:
* Vulkan support
* Emoji support (although I'm not familiar enough with Cairo to know if shaping is part of the library)
* Rendering in compute shaders
* New platform support (like MacOS arm or Android)
Already many users have switched to Skia which continues to make progress in all of these areas (and which is much faster).
That would be its sister project Pango:
https://blogs.gnome.org/mclasen/2019/05/25/pango-future-dire...
Calling it dead implies that projects that are currently using it shouldn't use it anymore, but projects for which cairo as-is suffices will continue to work with the features that cairo already has, so why would they need to migrate?
Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.
Recent commits doesn't indicate much in terms of security, fit for use, or quality. All it indicates is recent commits, and hints at reachability of the authors if you need to ask them about their intent (if code is unclear) or for license alternatives (if the license is unsuitable).
Yeah, or it could be the opposite. The newer, shinier alternative could also be faster, less buggy alternative.
The only alternative is maintained by Google and is much harder to use.
But really, QPainter suffers from a lot of the same issues as Cairo (and then some). The main "problem" with them is that they are CPU bound. Both of them have OpenGL backends, but they are not "really" faster. There is also the fact that the Qt Company doesn't invest in it anymore since QtQuick2 was released. Because of that, it doesn't get some of the newer Skia features. So Cairo/QPainter are pretty good at server side rendering. Qt was never popular for that use case. Cairo used to own that market, but it's usage is declining due to the maintenance inactivity issues. Also, once upon a time Cairo was used in Firefox and Chrome, so it's SVGs tend to be rendered more accurately in modern browsers than Qt ones.
Skia itself is an unsustainable library to depend on. Its API and behaviour isn't stable. Google doesn't really care about non-Google use cases, so the CMake is broken 90%+ of the time. It adds a large maintenance burden on projects trying to use it. Distributions also hate it for being impossible to package reliably. In turn, it makes hard for smaller projects to migrate away from Cairo because users have an easier time getting their hands on Cairo than Skia.
(bias disclaimer: I worked with both as a KDE dev and as the AwesomeWM co-maintainer, a Cairo based project. A lot of the recent unreleased Cairo commits originates from the AwesomeWM community, but not from me)
That was the theory behind Cairo. In practice it never worked out and Cairo wasn't able to fully exploit hardware accelerated rendering. Cairo was very complex so it wasn't easy for the maintainers to keep all the various backends up to date.
If something has bugs or lacks features, then it needs maintenance. "Maintenance" for pushing out versions to fulfill expectations of "maintained" is pointless.
What is the big O run time of the various functions? Sometimes someone pops in from a university and knows how to improve an algorithm and shrink its runtime, perhaps based on the latest graphics research, perhaps based on old research which was somehow missed.
That's exactly it, this is essentially a contributor saying "hey, there are a bunch of contributions, can a maintainer please check in this month?" If you don't check in once a week/month, then you're not good.
In Cairo's case: Waaaaay too many projects depend on Cairo as a dependency either through GTK+ or otherwise. You will be breaking heaps of backwards compatibility.
In the past few years X.org had some major ancient holes discovered. If the authors of the fixes hadn't bothered writing the fixes, I doubt many other people would have stepped up.
We like to talk about software as architecture. You design a thing. You build a thing. It is built.
Except, real architecture doesn't work that way, and it turns out metaphoric architecture doesn't either.
If you walk down the street long enough you will eventually see a house that is unmaintained. It wasn't broken to begin with, and no one broke it outright, but over time the paint (and shingles) have peeled, rot has set in, and now the foundation is cracked and the frame is starting to sag.
Even maintenance isn't always safe. Sometimes you're up on the cathedral, fixing the roof, someone flicks a cigarette butt the wrong way and it doesn't matter how well it was architected 800 years ago, it's on fire now.
We thought our digital creations were free from the decay or physical ones are subject to, but it turns out we were wrong, because even if the bits themselves don't actually rot, the digital environment they are living in constantly changes, and it amounts to the same thing.
Development seems active. Last MR/PR merged in was 2 days ago[1]. Isn't all that's lacking is someone to pack changes into a tarball and call it a release?
[1] https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests?...
Can't this be automated?
I doubt people would appreciate if I wrote them build scripts in Scala ;-)
Meaning, you just volunteered.