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

David Turner david at freetype.org
Fri Feb 2 02:12:43 PST 2007


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 :-)

On Fri, 2 Feb 2007 09:31:25 +0100, "Eric Faurot" <eric.faurot at gmail.com> said:
> > What was the big issue? Cairo has never supported rendering to an
> > 8-bit pseudocolor display, ever.
> 
> 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.

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

> 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.

> - 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.

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

> 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 ?

> 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.

> 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

> Come on, you have had the following in your source
> (cairo-xlib-surface.c) for how long?
> 
> 	/*
> 	 * XXX This can't work.  We must convert the data to one of the
> 	 * supported pixman formats.  Pixman needs another function
> 	 * which takes data in an arbitrary format and converts it
> 	 * to something supported by that library.
> 	 */
> 
> This results in crashes for quite a lot of people actually.  I see
> plenty of evidence that xlib is actually not supported as a backend.
> 
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

> I don't want to do this for the following reasons (which might also
> give you some possible idea on how to attract developers):
> 
> - I don't want to be forced to use git
> - I don't want to be forced to use bugzilla
> - I am not interested in contributing to a (L)GPL project.
> - I don't have time to follow cairo development
> 

Just a few points:

- You don't need to use bugzilla to contribute (I certainly don't)

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

- 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.

- 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

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


Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


More information about the cairo mailing list