[cairo] Getting mozilla-specific changes merged in

[Carl Worth]

On Mon, 15 May 2006 13:58:43 -0700, "Vladimir Vukicevic" wrote:
> On 5/15/06, Carl Worth <cworth at cworth.org> wrote:
> > [1] It would be nice to be able to use "stock" cairo with firefox
> > --enable-system-cairo, and I think we're really close to that
> > now. Vladimir, I've been expecting some comments on the merging I did
> > of mozilla patches. Can I expect that soon? If there's more that needs
> > to be done I'd really like to see it happen before cairo 1.2 if
> > possible.
> 
> I think we can get very close; I've been swamped the past two weeks,
> and am at XTech this week and on vacation next week.  I'll do some
> diffs and figure out what's changed between what we have and what's at
> the tip of the main cairo git branch.  Either way, though, even if we
> can build with a "system cairo" for 1.2, we won't guarantee that that
> will last until we branch for Firefox 3, which probably won't happen
> until early next year.  But we should certainly try to converge right
> now if we can.

Vladimir,

Thanks for the update. There are really two separate issues here. The
first issue is about what should be in cairo 1.2, and the second issue
is about making sure that cairo's master branch is useful for mozilla
in general.

Let's look at the 1.2 issues first, since they are more pressing:

1) We've already got new, mozilla-motivated API in the 1.1
   snapshots. So we must ensure that we ship the right version of this
   stuff in 1.2 (I don't want to deprecate it immediately afterwards,
   for example).

   I think this really comes down just to cairo_get_group_target. For
   which there are two issues:

	a. I asked earlier if we might want to just use
	   cairo_get_target instead. Any thoughts?

	b. What's been merged so far is missing the change you have
	   later that adds the offset. I also asked if this could be
	   queried through existing API (get_device_offset) or
	   not. Thoughts?

2) If there are other, known API additions that are desirable, it
   would be most convenient to get them into 1.2 where we are already
   doing API additions and an ABI bump. I think this comes down to
   Robert's extract_clip_rectangle stuff, (and I believe he's promised
   a patch to come for this). Robert?

Then, there's the separate issue of letting cairo master satisfy
mozilla's --enable-system-cairo. Basically, we've had a situation for
a long time where the standard cairo and the mozilla copy of cairo
have been very divergent. I'd really like eliminate that permanently.

I know that it's a pain for mozilla to manage a divergent tree. The
pain means that mozilla pulls from upstream cairo less frequently,
which means that users of mozilla see upstream features/fixes at a
slower rate.

Meanwhile, cairo development can benefit a lot from having ready
access to mozilla as a means of testing. I've been using it to
demonstrate new capabilities in the PDF backend, but each time I do
this, I've had to also go through some painful merging.

So, I'd like to get all synched up now and stay that way as a matter
of course. And I'm talking about the head of development here,
independent of any releases of cairo.

Now, mozilla might need to hold on to a stock set of patches for its
own build environment, or its internalizing of cairo---and that's
fine. It's not as pressing to get that synched up. But the rest of it
I'd like to have landed in cairo proper sooner rather than later.

I think we've got the major part of the merging behind us now that the
device_offset and push/pop_group stuff has landed. From what's left,
most of it looks very straightforward, and it's mostly internal fixes
that don't touch the API at all, (except the get_group_target and
extract_clip stuff I discussed above).

So, with most of this, I'd like the mozilla developers to start
feeling more comfortable about just pushing those kinds of fixes out
to cairo's master tree; particularly for the win32 and quartz backends
where the mozilla developers are now the primary maintainers anyway.

If you want review before you feel comfortable pushing, then please
mail the patches to the list first. Otherwise, go ahead and push, and
I'll still at least skim things as they come into the tree.

It is still a requirement that all API changes/additions be discussed
on the list first---I'm definitely more picky about those. (And
there's still an unresolved issue of the Y-axis flipping parameter in
the quartz backend as far as I'm concerned).

Anyway, more than just talking about this stuff, I want to see it
happen. So I've done some work along these lines. When I pulled in the
device_offset and push/pop_group stuff I did it by cherry-picking the
parts I liked rather than asking Vladimir to go back and arrange the
parts into a branch I could merge directly. That was perhaps easier on
Vladimir at the time, but it does mean that resolving his branch now
is a lot harder than it would have been otherwise.

So I've made an attempt at resolving the mozilla branch myself. My
attempt is in the mozilla-rebuilt branch within my personal tree. It
should be fetchable with:

git fetch git://git.cairographics.org/~cworth/cairo mozilla-rebuilt:mozilla-rebuilt

It's also browsable online at:

http://gitweb.cairographics.org/?p=users-cworth-cairo;a=shortlog;h=mozilla-rebuilt

(I do plan to try fixing up our gitweb URLs so that its possible to
publish a single URL for both of the above purposes.)

I generated this branch by using git-cherry to examine patches in my
mozilla-merged branch (maybe I should have used one of Vladimir's but
I think the result is the same) that had not yet been applied to
cairo's master branch. The git-cherry output included a lot of noise
about patches that it thought weren't applied but that I "knew" were,
(basically, anything about device_offset or push/pop_group). This is
because when I cherry-picked these I didn't always pick them exactly
as they existed in the original branch, (I often merged one feature
change with a couple of subsequent "oops, didn't mean that part" kinds
of things). It is these exact same patches that lead to nasty
conflicts if one tries to let git merge one of the old mozilla
branches with the latest cairo master.

Anyway, so I ignored any of those patches, and I also ignored the "new
quartz" patches, and I tried to cherry-pick the rest. I won't promise
that I didn't miss anything, but I hope that what I've done there
would be useful.

From a quick skim, it looks like most of what I've put in this branch,
(again, except for the public API changes: get_group_target and
extract_clip), could likely be pushed out to the master branch right
away. But I'll leave that to Vlad or others who have more "ownership"
of these changes than I do.

-Carl

PS. I'm just building mozilla against this branch now. When that's
done I'll follow up to show how PDF output from it is looking with
both the recent type3 stuff as well as Kristian's TrueType font
embedding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060517/a10b8f59/attachment.pgp