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

[Eric Faurot]

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

> I have the patch you sent to this list on March 27. Is that still
> current?

No, my latest patch is against 1.2.6.  See the attachment.

I have tried it on amd64/nvidia, macppc/ati and macppc/wsfb (openbsd
framebuffer), at 8 16 and 24 bit depth, with and without RENDER, on
local X and through ssh.

It does not work on local X for depths 8 and 16 if RENDER is enabled.
Disabling RENDER works everywhere.  The strange thing is I was almost
sure it worked with an older patch.  I need to enable the workarounds
even if RENDER is available.


> So, when you've got a lot of users that would be affected by a
> regression in an important package like GTK+, that sounds to me like
> an opportunity to apply that pressure to improve GTK+, (which could
> have, in turn, fixed this in cairo---which, as you said, is really the
> only place to fix the issue). But when the distribution masks the
> issue, all that good pressure-to-improve just disappears.

Well, I am not maintaining gtk port myself so I cannot say, but I
think the best solution is to fix the problem at its root directly.


> > - I don't want to be forced to use git
>
> Feel free not to. What would be perfectly fine at this point is to see
> a complete patch generated from the 1.3.12 snapshot. And for future
> major releases, it would be great to get at least one positive test
> report during the series of experimental snapshots leading up to the
> major release.
>
> I'd be glad to accept emailed patches against the latest snapshots and
> integrate them with git. I don't have any problem doing that work.

All right, we can do that.


> > - I don't want to be forced to use bugzilla
>
> Please ignore it then. I personally can't stand bugzilla. I think this
> mailing list works much better. Just take a look at how much more
> action we're getting on this issue with this thread than with a
> bugzilla entry.

Then I'd suggest that you, as the project leader, just shutdown this
tracker.  It is obviously affecting communication and it is diluting
efforts.  That is just my opinion, but I really suspect this awful
piece of s....oftware is actually discouraging many people from
reporting and contributing useful things.


> > - I am not interested in contributing to a (L)GPL project.
>
> That one I can't help you with. Do you mean you're not interested in
> sending any patches for use in cairo under its existing license? If
> that's the case, then I'm not sure why we're even having this
> conversation.

Actually this point is just one aspect of the general time issue.  I
like cairo, but when I choose how I spend the free time I am
dedicating to free software, the license thing is also part of the
equation.  Now for my patches, of course I'd be glad if they were
integrated into cairo: improvement for cairo, wider audience to get
feedback, less work for me, helps everybody.  It is a win-win
situation.


> > - I don't have time to follow cairo development
>
> That's fine. I understand that cairo's not your primary
> concern. Fortunately I don't think the maintenance burden we're
> talking about here is actually all that large. Would you be OK if I
> emailed you in advance of major releases, (currently that looks like
> no more than about twice a year)? Also, could I email you in the
> occasional situation where we have to modify this code and might have
> some questions?
>
> If you're willing to own the code in that fashion, that's fine with
> me. I would imagine this really isn't more work than you're already
> committed to do to maintain the patch within OpenBSD.

All of this sounds fine.  Now, to explain the "compromise" I was
talking about.  My work on cairo is currently following the OpenBSD
schedule.  I take whatever the latest stable release is when needed,
patch it and package it.  Now that would mean I must follow the cairo
release cycle too, including experimental releases.  I can do that if
it is not too costly for me, and if that does not mean completely
rewriting my unclean patch by myself. About the patch itself, I needed
something simple that would fix the problem right away, based on the
stable cairo release that we ship, without having to spend too much
time on it.  Nice design and efficiency is obviously not a priority
for me.  My goal is simplicity and correctness.

So to sum up:

What I would like is:

- comments from cairo devs about what is good or bad with this patch,
  possibly with ideas on how to improve it.
- notification about internal changes to cairo that may affect this
  part if the code.

What I can do is:

- improve the patch based on this feedback.
- maintain that specific part of the code from release to release if
  it is ultimately integrated into cairo.

What I don't want to do is:

- provide fixes for every stable and experimental cairo releases if it
  is not getting anywhere.
- partly rewrite cairo internals to address the problem on a more
  general level.


Cheers,
Eric.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-src_cairo-xlib-surface_c
Type: application/octet-stream
Size: 14009 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070203/f9211526/patch-src_cairo-xlib-surface_c-0001.obj