[cairo] Should cairo support pseudocolor? (was: bug 4945: six months to fix a bug ?)

[Eric Faurot]

On 2/2/07, David Turner <david at freetype.org> wrote:
> Salut Eric,
>
> I'm not a big Cairo contributor, but I'm the author of another pretty
> popular open-source library, and I had my share of user-submitted patches
> that "fix their problem" while breaking other things they don't care
> about. I thus somehow feel entitled to answer to your post :-)

That is the best way to get things moving. :)

> On Fri, 2 Feb 2007 09:31:25 +0100, "Eric Faurot" <eric.faurot at gmail.com> said:

> > The problem is not about cairo supporting pseudocolor or not. It is
> > about cairo supporting xlib or not.
>
> that's a pretty poor argument. It means that Cairo should also support
> 1-bit displays as well as gray-level ones, not counting tons of legacy
> pixel formats that were unique to some weird graphics cards of the
> past.

Yes and it this should be fixed it if it is actually needed. And I'll
do that for OpenBSD if it is requested.  By the way, somebody sent me
a patch for my fix on Solaris 9.  I thank him.  Now, should I fix not
only OpenBSD but also centralize the fix for all the cairo users left
behind?

> I predict that this is not gonna happen for purely practical reasons.

There is no prediction involved here. It is already a reported problem
for 8bit pseudocolor.

> > It is not an extra functionality.  You have an xlib backend which is
> > broken because it does not work with xlib.  So if you want to be
> > consistent you have two options:
>
> Consistency for consistency's sake is a waste of time. Forget about
> that.

That is not simply consistency for consistency.  There are people left
behind here, very practically.

> > - fix the xlib backend because it is supposed to be an officially
> >   supported backend in your stable branch,
> > - remove the xlib backend from stable releases, because it is not
> >   stable.
> >
> Unfortunately for you, it's pretty stable for what it's *designed* for,
> there is no reason it's going to disappear anytime soon.

And what exactly is it designed for?  To operate only on true color
linear framebuffers exclusively?  It can not operate on pseudo-color
backend?  Are you going to tell me that I cannot print cairo-generated
postscript on a B&W printer?

> As for "fixing it", the problem is that there is nobody to support
> (i.e. frequently test/maintain) pseudo-colors in the Cairo sources.

Which I think was the reason for this thread. It is broken but nobody
wants to fix it.  Do the developers care about their users?

> > Of course, you will never do the latter because of gtk. Unless you
> > tell them that they had to be more "conscious" when they made the
> > decision to depend on your software.
>
> But, fact is that *they* had to be more conscious, unless they also
> don't care about pseudo-color terminals. Why don't you complain to
> the GTK team, and all other projects that are starting to use Cairo ?

Come on... should I really explain this to you? David Turner?  Because
then we would have to fix not only gtk, but every other lib or app
that link with cairo, and for absolutely *no* good reason since the
issue can very well be handled in cairo.  So, it is being very very
practical to say that cairo must be fixed.

> > Well, you have the patch, you have probably guessed how it works, and
> > I am already maintaining this patch, as far as OpenBSD is concerned.
> > The only problem is that I am not interested in maintaining it as part
> > of cairo itself.
> >
>
> In case you didn't understand Carl's invitation, all you need is find
> someone who is interested in maintaining and testing this enhancement
> as part of Cairo itself.
>
> Sadly, you won't find a lot of people who do, but it's certainly
> possible. That none of the Cairo hackers is interested is not surprising
> given that they consciously designed the library to avoid this case.

And me, without getting involved too much into cairo internals, I
simply wrote a couple of lines that fix the problem without disrupting
their precious design.  What is so bad about it?  People can now use
their gtk apps again on X.  Is that a regression?  AFAIR, when I asked
about clues on how to fix it on the mailing, it resulted in lots of
very interresting discussions about dithering and stuff, which leads
to nothing, practically.  So I simply did what seemed the most
straightforward acceptable, practical, solution.  If it is not, then
at least you could have told me why, and why your users wants to
have it integrated into cairo.

> > It would be a new feature if you introduced some kind of abstraction for
> > pseudocolors in the cairo API. Here we are not talking about this. It
> > is just about fixing the xlib backend, which is broken.
> >
> no, it's not broken

Yes it is. My apps crash where it should not. I call it broken.

> that's true, XLib, with all it strange arbitrary pixel formats is not
> fully supported. However that's not exactly a problem in the eye of the
> Cairo hackers.
>
> Again, find someone willing to maintain the changes in the Cairo source
> tree, and the problem will be solved.
>
> > > Note that many distributions do ship cairo without any extra patches
> > > in this area. To each his own of course.
> >
> > Doesn't that mean there is something wrong, then?
> >
>
> no, it means that most distributions are perfectly happy with the current
> Cairo sources, i.e. they don't give a fuck about pseudo-colors

Actually I misread the original sentence.  But anyway I don't care
about other distributions shipping broken packages.


> Just a few points:
>
> - You don't need to use bugzilla to contribute (I certainly don't)

I got excatly zero reply from cairo devs when I submitted my patch to
the list.  I have been contacted off-list way by someone who found my
patch more or less by accident, who was happy about it and who told me
that I really had to submit it to the tracker to give it proper
visibility. So yes, I would need to use bugzilla.

By the way, given the number of entries that have been marked as
"duplicate of this bug" (which status is critical by the way), I can
guess that this is an issue for your users. Very practically.

> - Cairo is also dually licensed under the MPL. You might find this
>   more compatible with your tastes

Not really.  It is certainly off-topic, but I would like it better if
coders where actually concerned about writing proper code, rather than
hydra-headed free software licenses which are longer than Microsoft
EULA.

> - You don't need to master git to be the maintainer of pseudo-color
>   support in Cairo, once the patch is integrated (which can be done
>   by other people, by the way), you'll mainly need to perform
>   "git pull" and re-run compilation + test suite + installation to
>   check that everything works as expected
>
>   and this is said by someone (me) who hates git with a passion.

And then someone comes up with a brand new versioning system for his
pet project, then as a casual contributor I need to deal with cvs,
svn, git, darcs, godknowswhat... Then they decide the rewrite "make",
then "sh", and so on.  The problem is not git itself, the problem is
the process.

> - you don't need to follow all of cairo's development, simply try the
>   latest versions before a new release to see if it still runs
>   properly; and if not, inform the mailing list

If it is so simple why can't the devs do that already?

> - sometimes in life, compromise is needed to get where you want

For me the compromise is clear.  I fix it for OpenBSD, period.  It
helps others, fine.  Even better if upstream developers could take
their responsibilities and fix the problem.

> Hope this helps,

Sure.

Eric.