[Cairo] virtualizing the surface interface

[Carl Worth]

On Sep 26, Jamey Sharp wrote:
 > So I've renamed it to cairo_surface_backend. Better?

Yes I like that.

 > Does this policy apply to structure fields too? I added an "impl" field
 > to cairo_surface_t; would you prefer a different name?

Personally, I use identifiers which match the type name whenever
possible. So I would use:

	const cairo_surface_backend_t *backend;

 > The IcImage-based stuff wants to follow this convention too, I
 > think, and I partially updated it.

We might move all of the IcImage stuff into a cairo_image_surface.c or
some such. But we might wait until libic gets renamed first. Or we
could just leave it in cairo_surface.c as a core, non-virtual
implementation.

 > Done; cairo-xlib.h has prototypes for cairo_xlib_surface_create and
 > cairo_set_target_drawable (which I think needs to be renamed too).

Perhaps cairo_set_xlib_target? cairo_set_target_xlib?
cairo_target_xlib? I'm not feeling inspired today, anyone else?

 > I couldn't get __external_linkage to work at all in this header,
 > though, and I have no idea why, so I just commented that part out.

Looks like the magic that isn't there is what is in cairo.h:

	#ifdef _CAIROINT_H_
	#include <slim_export.h>
	#else
	#include <slim_import.h>
	#endif

So we'll have to come up with a similar approach for cairo-xlib.h.

 > Naturally, this meant I had to change apps that were using Cairo, to add
 > #include <cairo-xlib.h>, but once I did so the cairo-demo apps built and
 > ran fine.

Yes, things run fine here. Feel free to commit your changes if you'd
like. I haven't gone over it all with a microscope, but there's no
obvious breakage from the outside, and we can fix internal stuff just
as easily within CVS instead of via patch discussion on the list. Do
see my note below on the Xft stuff first, and don't forget to fill out
a ChangeLog entry.

 > I'll appreciate it if somebody else works out the right build
 > system magic to build Xlib support only if it's available.

Me too. I'm doing my best to remain as ignorant as possible of
autoconf alchemy. I imagine there's a user that doesn't actually want
to run the xlib backend that will be sufficiently motivated to
contribute the effort needed.

 > I've removed the include of Xft.h, and #if 0'd a little more code that
 > broke afterward. Too many things depended on the Render header for me to
 > figure out what to do with them all, though, which seems vaguely
 > bad.

I've already got code that relies on the "basic" text support in
Cairo. So I don't want these to be #if 0'd. We can push them down into
backend-specific files though. Even before that, with the right
autoconf magic, I would be fine if these were wrapped in "#if HAS_XFT"
or whatever.

 > I was wondering if it wouldn't make sense to just re-implement Xft on
 > top of Cairo

There's definitely going to be some level of code sharing here. The
most urgent need is for Cairo to gain the ability to draw text onto
image surfaces. So the plan is to crib from Xft as needed and pile a
bunch of code into libic. Once that's working we can decide a better
relationship between Xft and libic. Perhaps common code could be
pushed out into a support library used by both.

 > Don't thank me until you've checked it - did I mention I'd never read
 > Cairo sources before yesterday? If having a Picture reference a Pixmap
 > is supposed to cause XFreePixmap to not actually free the Pixmap (as
 > something I read in one of these list mails seemed to suggest) then the
 > code ought to have been fine as is. I just thought it looked funny, so I
 > changed it.

Yes, your fix is fine. It's much more legible. I would name the flag
"owns_pixmap" rather than "free_pixmap" but obviously that's not a big
deal.

 > How do you find out that you've got a pixmap leak, anyway?  Was the
 > X server getting OOM killed or something?

No need for it to get that far out of hand. Mark Vojkovich wrote the
X-Resource extension to report X server resources on a per-client
basis. I don't know if there's a standard client in the distribution,
but I used the sample that Mark sent out with his announcement of the
extension:

http://mail.gnome.org/archives/gnome-hackers-readonly/2002-March/msg00127.html

-Carl