<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p> </p>
<div class="moz-forward-container">
<div class="moz-cite-prefix">On 4/26/21 3:17 PM, Emmanuele Bassi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Hi;</div>
<div dir="ltr"><br>
</div>
<div>thanks for your perspective. It's really appreciated.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 26 Apr 2021 at
11:28, Heiko Lewin <<a href="mailto:hlewin@gmx.de"
moz-do-not-send="true">hlewin@gmx.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr">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.<br>
</div>
</blockquote>
<p>I am not sure what changes you mean and haven't seen
any discussion not MRs for them, but I will try to
make some general points. cairo is a relatively old
software project. You can see already where things
that did not really fit into the design were added.
This makes adding new APIs problematic. Of course it
comes down to the concrete matter of things you want
to add, but in general my advice, whenever it is
possible to layer some feature on top of cairo, would
be to do so. There are things that cannot be done
"from the outside", though, and for these things
chances are you will find an open ear to listen to
ideas.</p>
</div>
</blockquote>
<div>From the GTK developers perspective, we *already* add
things on the "outside" of Cairo. Sadly, glyph composition
is still something that has to live in multiple
components, and its implementation is dictated by how text
rendering works more than considerations on the initial
Cairo design.</div>
</div>
</div>
</blockquote>
Sure - supporting Unicode properly is a huge mess. Which is why I
wouldn't even try to put that into cairo. Speaking of making
development easier. I do not see why cairo should do
fontconfig-stuff either, but I understand it is in the lib and has
some users. Who cares if it violates the principle of separation
of concerns?<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>The text rendering stack on Linux is already fairly
complex, and in various cases its complexity is the result
of Conway's Law more than actual software engineering
practices. This situation isn't helped if entire
components simply cease to function as part of the stack.<br>
</div>
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr"><br>
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.<br>
</div>
</blockquote>
As cairo is seriously lacking development resources, you
then should have a look at the unstable features you
mentioned and see what you can do to fix the problem. I
think most issues can be fixed without expert knowledge
but only require someone to dig into the code - if the
features are already implemented, that is. If you
stumble about something that does need special insight,
well.... good luck. Most of the code is orphaned.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, that's why I want to drop a lot of this orphaned
code—especially the one that is known to never be enabled.
<br>
</div>
<blockquote class="gmail_quote">
<div><br>
<blockquote type="cite">
<div dir="ltr"> 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.<br>
<br>
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.<br>
</div>
</blockquote>
<p>As a description of a symptom this might be true, of
course. But the easy advice would be to not enable any
feature that you don't miss.</p>
</div>
</blockquote>
<div>This is not "the easy" way, sadly.</div>
<div><br>
</div>
<div>Code costs, even code that isn't built. Every time you
have to change things, you have to verify that your change
covers every use case—except people don't do that, because
nobody builds niche backends. The test suite doesn't even
run for them: it barely runs for the image surface.<br>
</div>
<div><br>
</div>
<div class="gmail_quote">More importantly: it gives out a
false perception of what Cairo can do, and makes people
waste their time. People look at Cairo today and think
that cairo-gl is a viable solution for rendering vectors
on the GPU. It is very much not, unless you like your
rendering to be wrong and slow; but maybe that's enough
for your use case—except that now that you sunk a ton of
time and effort, you realise that nobody is actually
shipping Cairo with the GL support enabled. Anywhere. Now
you have to figure out a replacement, and you will never
use Cairo again.</div>
</div>
</div>
</blockquote>
<p>Yes, and PDF type 3 fonts are broken as well. So that would
have to be removed. The test suite prints warnings and errors
for the PS backend and nobody cares. So get rid of it? We can
continue this list.</p>
<p>The code being used is no guaratee for not being orphaned. It
just is frozen and does what it ever did.<br>
</p>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Leaving dead code in a project is
an abdication of responsibility—even when done in the hope
that somebody will turn up and fix it. Spoiler: nobody
will, because the broken code will drift further and
further, and at some point it'll require a rewrite, which
is a *daunting* perspective for anybody, let alone a first
time contributor.</div>
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div>
<p>I am not quite sure what you mean by the care for
the whole project versus "fiefdoms". Different parts
of cairo were written by different people who seem
to have lost interest in the course of time. This,
of course, is perfectly fine, but now it can be felt
that major parts of cairo are lacking experts. You
will definitely not find the monarch of backend X
who closely watches everything that happens in his
domain and strives to realize his greater plan -
unfortunately.</p>
</div>
</blockquote>
<div>Well, at the very least we still have people who
understand the Xlib and XCB backends; we might even have
people with enough knowledge, or willingness to hack on
the Windows backend and the Quartz. The problem is, of
course, that we have a chicken and egg problem: nobody
feels entitled to take ownership of some piece of code
because they don't know if their changes will ever be
released.</div>
</div>
</div>
</div>
</blockquote>
Exactly. Without people who can test and/or review commits things
tend to sit there for a long time. As can be seen with numerous
MRs.<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>As an example: for a long while, the GTK project has
had issues finding people willing to contribute to the
Windows and macOS backends. Our code was not great, but
more importantly: the people who originally wrote it
either left the project or simply stopped caring. This
kept people from contributing, and in turn made people
work around issues in GTK even though they could
contribute a fix upstream.<br>
</div>
<div><br>
</div>
<div>We ended up breaking this spiral through the
introduction of a reliable CI pipeline, which allowed us
to at least know if a change would build—the minimum bar
to clear. We ensured that our build system would work on
every platform. We started refactoring our own internals
to make sure that people could contribute to GTK without
having to learn X11. We reduced the amount of build
options and toggles, to create a reliable development
environment. We also decided to empower more people with
small contributions: not by telling them "now you
maintain this subsystem", but involving them into the
decisions regarding larger changes in the project. We
turned fiefdoms into commons.<br>
</div>
<div><br>
</div>
<div>Many of these changes are the result of better
infrastructure—the same infrastructure Freedesktop now
has—but more importantly: it was a change in how we
maintain the project.<br>
</div>
</div>
</div>
</div>
</blockquote>
Sorry, I can not envision bigger changes to cairo as it is. There
are other, newer projects. cairo is the kind of library you use if
you do not want your code broken by upstream patches.<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div> <br>
<p>In the eyes of the lack of dev-resources this might
seem good and well. But how do you come to this
distinction? From my point of view the "supported
backends" are just as abandoned as is the rest. For
example, there is no actve developer with a deeper
understanding of PDF, or PS. The quartz-backend
sometimes gets fixed by mac-users that stumble upon
bugs (thanks for that!), but has open issues that
nobody can really work on.</p>
</div>
</blockquote>
<div>
<div>The list of "supported" backends I identified are
actually backends that are a) enabled by every common
Linux distribution b) used by GTK and Firefox. In
other words: those are the backends that are exercised
by the vast majority of remaining Cairo users.<br>
</div>
<div><br>
</div>
<div>The Xlib backend is used by GTK on X11; the Windows
backend is used by GTK on Windows; the Quartz backend
is, for all its problems, still used by GTK3 on macOS.
The PS and PDF backends are used by GTK applications
when it comes to printing, as well as Firefox on
Linux/Unix.<br>
</div>
<div><br>
</div>
<div>If there are issues on those, we can at least
verify that they don't regress. To be honest, I'd be
more than happy to drop the Quartz backend: it's
basically busted and has been so since the
introduction of color spaces and HiDPI displays on
macOS, almost 10 years ago.<br>
</div>
</div>
<blockquote class="gmail_quote">
<div>
<p>My stance on this issue would be more like: If
there are no concrete complaints, things seem to
work just fine. And if there are complaint: This is
open-source. Fix your problem!</p>
</div>
</blockquote>
<div>I'm sorry to say, but this is pretty terrible advice
and it demonstrably does not work—as you may have
noticed, nobody has shown up to fix Cairo. On the
contrary, projects have stopped using Cairo except for
very specific domains, and they are scrambling trying to
find replacements.<br>
</div>
</div>
</div>
</div>
</blockquote>
Well, I am here. I just do not believe that cairo will see much
further development. It is not suited for GPU acceleration, as you
pointed out, is written in pre-C99 and optimizes PLTs by hand. You
just do not write new stuff like that.<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> <br>
</div>
<div>In part this is caused by the design of Cairo, which
does not match what general purpose computers have been
moving towards over the past 15 years—dedicated GPU
cores with programmable pipelines; but I'd contend that
the biggest contributor to the exodus is literally the
uncertainty in how Cairo is maintained since Carl Worth
(and Chris Wilson) have left the project.<br>
</div>
<blockquote class="gmail_quote">
<div>
<p>It's not that I would find the proposal
indiscussable ( I have no real interest in those
backends - why not drop PS, Xlib, Win32 and Tee as
well? ), but I do not see a strong reason to do so.
Most of the removal-candidates on your list are
listed as experimantal/incomplete. That's it: if
someone has interest in working on those, they are
welcome. Lack of active development, however, cannot
be criterion for removal: You would have to throw
away far more than those...</p>
</div>
</blockquote>
<div>Why? And, also: why would it be a problem to throw
away more code?<br>
</div>
</div>
</div>
</div>
</blockquote>
<p> Because all cairo is, is an old library whose API was stable
for years and whose only purpose nowadays is not to break
existing, lazily maintained applications... That is how it is
used. For example, you wouldn't expect cairo to remove or
refactor it's API and breaking dependent applications. As the
feature set is more or less frozen in this way (GTK wouldn't use
cairo anymore if that wasn't the case. You already pointed that
out indirectly.), there is no point in making new features
easier to implement.<br>
</p>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>The Cairo-drm backend has been a science experiment
since day 1; it hasn't seen changes in the past 10
years, and it doesn't even build on recent versions of
the Linux DRM subsystem, as far as I can tell. The Qt
backend does not build, and it's another science
experiment, just like the old Skia backend was. DirectFB
is entirely abandoned upstream, to the point that the
domain itself has lapsed and it's now squatted by a
random blog. Cairo-cogl was another science experiment,
and Cogl is unmaintained upstream (I know: I was one of
the maintainers of Cogl, and we never used Cairo-cogl to
begin with).<br>
</div>
<div><br>
</div>
<div>The Cairo-GL backend is not enabled by any Linux
distribution; the only known consumer of that API was
WebKitGTK, which has moved on for its compositing
because cairo-gl is known to have performance issues and
because nobody would dare enable cairo-gl on platforms
shipping WebKitGTK.</div>
</div>
</div>
</div>
</blockquote>
<p> Well, it does build and you can even learn something from it.
The cairo website does not claim it was production-ready.<br>
</p>
<p> "Less code is less code to maintain" does not hold if
"maintenance = nothing". That is striking, of course. I do not
know if I really wanted to say that...</p>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>In practice, all the backends I listed are either not
enabled by default because they are known to be broken,
or they are tied to unmaintained dependencies.</div>
<div><br>
</div>
<div>I know that people randomly show up to fix a backend
or two, every once in a while. I appreciate their work,
I really do, but a patch every five years is not a
sustainable maintenance position.</div>
<div><br>
</div>
<div>Plus, it's not like the code is erased from the whole
of existence; if people wish to resurrect a backend,
they can still find it in the Git history, or in older
stable branches.<br>
</div>
<blockquote class="gmail_quote">
<div>
<p>The reason you give (easier development) is
abstract in the light of concrete circumstances. If,
for example, a feature would need to be implemented
in (some) backends, you definately will have to
implement it in the image backend. If you have done
that you already have implemented the
default-fallback for backends lacking a specialized
implementation. Such a fallback isn't performant,
pretty or elegant but could be improved later - if
there is someone interested in doing so, that is.</p>
<p>You would have to come up with concrete proposals,
but in my eyes cairo is more or less "finished". No
new features, no new responsibilities. Improving
what is there by fixing bugs is the top priority.
cairo has a pretty narrow scope (vector graphics),
which makes it a viable choice if that is exactly
what you need. You don't get that often with less
than 2MB of library size these days. <br>
</p>
</div>
</blockquote>
<div>I value your perspective, but I'd like to point out
that it is *incredibly* narrow.</div>
<div><br>
</div>
<div>I do have to care about the whole desktop thing—both
Linux and not. Text rendering still very much relies on
Cairo, and text rendering does not cease to exist just
because we have figured out Unicode.<br>
</div>
<div><br>
</div>
<div>On top of that, while we have successfully moved a
lot of rendering to the GPU, Cairo is still very much
the fallback on various platforms.</div>
</div>
</div>
</div>
</blockquote>
I am sorry to say this, but the scope of things cairo can be used
for in good confidence is incredibly narrow. Having a look at the
bug-reports shows this, having a look at the source-code shows
why. No offense meant to contributors - even statistics show this:
If a project gets too many commits, gets too old and too complex
the error-rate raises drastically. One is better off starting a
new project at a certain point instead of trying to squeeze in
yet-another feature X.<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>Basically: while from a certain perspective Cairo
might be feature complete, it turns out that what Cairo
does cover more use cases than that, and in that regard,
Cairo is not "finished" at all.<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr"> 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.<br>
</div>
</blockquote>
<p>I am here. We still at least compile the gl backend.
I fix bugs. Now what? Have you fixed the PDF or quartz
backend recently? Those are not feature complete.</p>
<p>This is a bad argument of course. I hope you see why.
<br>
</p>
</div>
</blockquote>
<div>Thanks for fixing bugs, but I hope you see why random
fixes does not imply that the backend is maintained or
even used. At the very least, we know that the Quartz and
PDF backends *are* used, because they are enabled by
default and we know people use Cairo-based toolkits on
macOS, and print documents.<br>
</div>
</div>
</div>
</blockquote>
Which is why I think we should do our best to hold those things
together as good as we can. But I just cannot see how you can make
an argument about "maintained and unmaintained code" having a look
at the issue-tracker...<br>
<blockquote type="cite"
cite="mid:CALnHYQEqS0CcKQRFBkJsS0a_OvWmjFis1NAZTDBDmjZfob+RLQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr"><br>
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.<br>
</div>
</blockquote>
We recently had a short discussion about dropping
autotools recently. There are a few things autotools
does that are missing from meson as for now. Mostly the
release-packaging stuff. As for me: I will not port that
over. Maybe you should talk to Tim how this could be
accomplished. Despite of the fact that we currently use
autotools for cairo I would not really mind it
disappearing.<br>
</div>
</blockquote>
<div><br>
</div>
<div>A bunch of those scripts are all kinds of redundant.
Switching to Meson has the advantage of giving us a very
reliable "dist" command, which ensures that we have a
release archive that matches the contents of the Git
repository; it is not self-hosting, which reduces the
issues with the tarball containing random files. A bunch
of the tests done at release time can be moved to a dist
script. Finally, a lot of the checks should just be part
of the CI pipeline that runs for every merge request.
Having a Makefile rule upload tarballs on a remote server
is… quaint… and to be honest, I'd rather have releases
hosted on GitLab, as it would likely reduce the sysadmin
effort, and lower the barrier to contribution, since it
would remove the need to give out SSH access to people.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr"><br>
I have started these changes in a separate branch,
called "Tanis"[3] available on GitLab:<br>
<br>
<a
href="https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis"
target="_blank" moz-do-not-send="true">https://gitlab.freedesktop.org/ebassi/cairo/-/tree/tanis</a><br>
<br>
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.<br>
<br>
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.<br>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><br>
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.<br>
</div>
</blockquote>
<p>If you do updates frequently, I would advice to
always use the latest master version. Occasionally a
new bug might be introduced but if you look at the
list of previous issues it might seem that things can
only get better.</p>
</div>
</blockquote>
<div>That's not how things work in the larger free and open
source ecosystem, sadly.</div>
<div><br>
</div>
<div>Downstream distributors do not want to ship random Git
snapshots, and consumers of the Cairo API really want to
be able to depend on an actual stable release.</div>
<br>
<blockquote class="gmail_quote">
<div>
<blockquote type="cite">
<div dir="ltr"><br>
So, I guess my question is: would this plan be
acceptable to the people still involved with the
development of Cairo?<br>
</div>
</blockquote>
<p>To give some information: We use cairo in a
commercial product and I got into development by
fixing some simple issues that occurred in that scope.
Now I am deemed an active developer by some people and
try to have a look at merge-requests and new issues. I
occasionally do work on cairo that is not covered by
the commercial interest.</p>
<p>I would be fine with the removal of backends as I do
not use them. But when talking about responsibility I
have to say, I do not know. Every now and then someone
comes along who does seem to use the more exotic
stuff. And - given that cairo is free and open-source
- what right would I have to remove code that
seemingly does not cause any problems? You say people
enable stuff and realize it does not work. You say it
would ease development to remove backends. From what I
see I just cannot say I am sure, you are right.</p>
<p>I do not feel comfortable making radical decisions on
such an old project.</p>
</div>
</blockquote>
<div>Which is why I volunteer for that. I am much more
comfortable with this, and I think one of the problems
with Cairo as it stands today is that nobody feels
empowered to make *any* decision.<br>
</div>
</div>
</div>
</blockquote>
<p> Good luck.</p>
<p>Heiko</p>
</div>
</body>
</html>