[Cairo] virtualizing the surface interface

[Jamey Sharp]

OK, you can find both my previously-posted patch (cairo-virt-v1.patch)
and a new v2 variant at http://pdx.freedesktop.org/~jamey/.

On 09/26 10:32AM, Carl Worth wrote:
> On Sep 26, Jamey Sharp wrote:
>  > The big changes are the introduction of the 'struct cairo_surface_impl'
>  > type, with function pointers for implementations of the operations on
>  > surfaces; 
> 
> Great. I prefer names without abbreviations, but I won't reject the
> patch because of that. It's just internal and I'll just rename the
> struct later if it bugs me too much.

Bart says you name things well and I should follow your conventions. :-)
So I've renamed it to cairo_surface_backend. Better?

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

>  > and the removal of almost all of Cairo's Xlib-specific code to
>  > a new source file called cairo_surface_xlib.c.
> 
> I had been planning to name the graphics system-specific surfaces
> cairo_foo_surface, so I would suggest cairo_xlib_surface.c
> instead.

Done, and most of the functions in that file are now named like
cairo_xlib_surface too. (I believe all of the exceptions are declared
static.) The IcImage-based stuff wants to follow this convention too, I
think, and I partially updated it.

> The idea was that the user would then get access to all
> Xlib-dependent functionality by including cairo-xlib.h. (Yes, there's
> still the issue about how to name the font system-specific headers.)
> 
> Similarly, I'd like to rename cairo_surface_create_for_drawable to
> cairo_xlib_surface_create and move it from cairo.h to cairo-xlib.h.

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

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. I'll appreciate it if somebody else works out the right build
system magic to build Xlib support only if it's available.

>  > The remaining X dependencies are on Xft (in cairo_gstate.c and
>  > cairo_font.c), and this patch #if 0's those bits into no-ops. I
>  > don't understand fonts well enough to fix that yet, so I'm hoping
>  > somebody else will. :-)
> 
> The Xft dependencies in cairo_gstate are bogus. These should be pushed
> down one level. Then we should probably virtualize cairo_font in a
> manner similar to cairo_surface. There are probably still some
> unresolved issue about the interface between the various cairo_font
> and cairo_surface implementations. Those should become more clear as
> the new font API work comes together, (I'm hoping to see something
> from Graydon soon).

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 was wondering if it wouldn't make sense to just re-implement Xft on
top of Cairo - surely there's a ton of code doing things like
arc-rendering or client-side compositing or something that is duplicated
in both libraries? Then you get Xft on every output device supported by
Cairo, too, with interesting consequences when Cairo's Postscript
backend is used for printing things that were rendered on-screen with
the XCB backend. It seems like a big win to me. I'm willing to try doing
it myself if you want.

Basically, I'm inclined to think there are too many text APIs already,
and that Cairo shouldn't provide yet another. Am I wrong?

>  > For the moment, I've chosen to prefer the server, compositing on
>  > the client only if the server can't do it or the destination is not
>  > on an X display. The existing code chose the other way.
> 
> I know the decisions about where to do compositing in the existing
> code are nowhere near optimal. There is some interesting
> experimentation to be done about where data lives, (library, server
> main memory, or server video memory) and how it moves.

Fortunately, the cairo_surface architecture makes this experimentation
pretty easy, I think. I was just curious if the existing choice had a
rationale or just seemed more natural at the time or something.

> Since nobody's complained I know that nobody has tried to use it. The
> cool part of the library is that supporting this bizarre case isn't
> much work; it just falls out of the architecture.

<aol>Yes, I thought that was pretty cool too.</aol>

When I understand the library a bit better I want to try writing some
test apps for the multi-display case, and the multi-backend case.

>  > I think this patch fixes the problem with GetGeometry being called on an
>  > already-freed Pixmap, without re-adding the pixmap leak.
> 
> Thanks for looking into this.

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. How do you find out that you've got a pixmap leak, anyway?
Was the X server getting OOM killed or something?

Need food. I'll stop typing now. See ya,

PS. Please don't CC me on list mail - I'm subscribed. Thanks.
-- 
Jamey Sharp <jamey at minilop.net> - http://minilop.net/
-------------- 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/20030926/cbd2b7fc/attachment.pgp