[cairo] freedesktop.org links in configure.in are wrong

[Jamey Sharp]

On Fri, 2005-05-13 at 17:05 -0700, Carl Worth wrote: 
> > Hope this helps. Thanks for playing with it!
> 
> It was fun. I ran into a few things in XCB that were harder than I
> thought they should be. I'll follow up on the xcb mailing list with
> those.

I look forward to that.

> I don't know that it's perfect, (particularly since I was just trying
> to type in XCB equivalents of Xlib calls rather than trying to come up
> with the "XCB way" of doing things".

Since you've put in all that effort, I figure the least I could do is
review the patch. ;-) Everything looks fine, but there were some
questions in comments that I can answer.

> +    geomrep = XCBGetGeometryReply(surface->dpy,
> +                                 XCBGetGeometry(surface->dpy, surface->drawable),
> +                                 0);
> +    /* XXX: I haven't looked closely at XCB yet to know why this might
> +     * fail. */
> +    if(!geomrep)
> +       return CAIRO_STATUS_NO_MEMORY;

Memory allocation failure is one possibility. More likely is an X error
being returned instead of the desired reply. Also, if the X server
connection closes, you should get a failure return from functions trying
to access server data that hadn't arrived before the loss of the
connection.

If you can usefully handle X errors from this request, then you should
pass a reference to a XCBGenericError* as the third argument to the
XCB...Reply function, and it will be filled in if an error occurs. By
passing a null pointer as above, any error will be inserted into the
event queue instead for the application to handle.

> +    /* XXX: This should try to use the XShm extension if available */

You may want to be using Vincent Torri's XCBImage library, which is a
port of XImage to XCB. The code is available from the xcb-util module of
XCB CVS. It includes the XImage functions from Xlib as well as the XShm
functions.

I seem to recall the XYPixmap support doesn't work and we don't
understand why, but the library is probably worth using regardless.
XCBImage should let you eliminate a fair amount of code from the Cairo
XCB backend, while more closely reflecting the Xlib backend; and Cairo
really shouldn't use XYPixmaps anyway. ;-)

> +       /* XCBGetImage from a window is dangerous because it can
> +        * produce errors if the window is unmapped or partially
> +        * outside the screen. We could check for errors and
> +        * retry, but to keep things simple, we just create a
> +        * temporary pixmap
> +        */

Again, XCB makes it easy to trap errors returned from particular
requests. I'm not sure how the "retry" aspect would work here, but if
the error-checking was the hard part under Xlib, then under XCB you
should just do the GetImage.

> +    /* XXX: What in the world is the drawable argument to XCBCreatePixmap ? */

The protocol specification will tell you: like most of XCB's API,
XCBCreatePixmap is tied directly to the underlying CreatePixmap request.

AFAICT, the root window of the specified drawable is used as the root
window for the new pixmap, which dictates the set of depths permitted
for the pixmap, and determines the set of other drawables that may be
specified with this pixmap in operations like CopyArea.

Presumably the test program should be able to test Cairo on any screen
of the display, though the code in the patch will always operate on the
first screen. A planned API change will make that more straightforward.
In the meantime, you could call XCBParseDisplay to get the screen number
if you wanted.

--Jamey