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

[Eric Faurot]

On 2/1/07, Carl Worth <cworth at cworth.org> wrote:

Hi, Carl and all.

(I also changed the title to focus on the real issue)

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

> Now, toolkits and applications that used to support rendering to 8-bit
> pseudocolor may have given up that capability when switching to
> cairo. But I hope in all cases that was a conscious decision on the
> part of the toolkit and application authors making the switch.
>
> So, your modified version of cairo supports something that the
> original cairo doesn't. You're perfectly within your rights to do
> something like that, but the support burden for the extra
> functionality is yours, not ours.

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:

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

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.

> > So, now I am wondering. Why is this bug-report still open, and not some
> > form of this patch integrated ?
>
> The easy answer is that cairo doesn't (and never has) support 8-bit
> pseudocolor visuals.

Again, this is not the question.

> If that's going to change, then someone that _is_ interested in cairo
> is going to have to step up and own the problem, (meaning that they're
> willing to maintain the support into the future). And first, there
> should be some discussion on this mailing list about what "support
> 8-bit pseudocolor" actually means for cairo. Should cairo be
> installing its own color map with a color cube and a gray ramp? Should
> it just use whatever colors it happens to find in the existing map
> even if the result is rainbow fringing? Should cairo start using
> dithering?
>
> That discussion could be as simple as Eric, (or someone else), saying:
>
>         Here's how the support should work. Here's a patch that does
>         it. I've tested this, and I'm willing to maintain/test this
>         code in the future.

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.

> And if there aren't any objections to the approach, they're really
> doesn't have to be much more discussion than that.
>
> > From what I understand, it looks like the cairo developers do not like
> > this patch too much, but hey, it does the job doesn't it ?
>
> Does it? We haven't even described what the job would be. This would
> be a new feature to be added to 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.

> > But seriously. You've got a major bug, a serviceable patch, and everybody
> > is sitting on their thumbs waiting for someone to fix the issue in a
> > cleaner way ? 9 months!!! this won't happen.
>
> I don't see a serviceable patch at all. I see three different patches
> that were generated against 3 different cairo versions, (1.0.x, 1.2.0,
> and 1.2.4). The most recent update to the patch came with th following
> disclaimer, (no offense to Dan here---he's just trying to make things
> work):
>
>         I can't claim to understand his changes (or any of cairo's
>         internals),
>
> and got the following response in testing:
>
>         The patch #6762 works indeed for 8-bit Pseudo-Color with
>         SUN-X-Servers, but breaks 24-Bit-True Color Visual
>         compatibility there
>
> So, I don't see a patch against the current version, and I see plenty
> of evidence that the patch that does exist isn't quite right yet.

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.

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

> > Integrate the darn patch already.
>
> Please understand that what you're asking is more than just pushing a
> patch-and-commit button. There's a support burden here as well. Your

Yes, there is support burden.  This is the price you pay when you
maintain something successful, and on which many other people depend.
That is why I wrote that patch, when I felt personally responsible of
my cairo port resulting in a gtk regression that required to backout
the whole gtk update just before an OpenBSD release.

> post itself has made arguments supporting the difficulty of supporting
> the feature: it's "complicated code" and people "have to fix the patch
> periodically".

> Currently, we don't have anyone, (that I know of), working on cairo
> that's willing to do that.

> But we're also always glad to accept new people. So if someone would
> like to step up for this, please let me know, and we'll be glad to
> welcome you as a cairo contributor. When people show good code and a
> willingness to maintain I'm very likely to say yes to a request for
> commit access to cairo's central repository.

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

> And, I would be quite glad to see the issue go away. I think I'm in
> strong agreement with Marc on that point.

Glad we all agree on that.

Cheers,
Eric.