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

[Jamey Sharp]

On Sun, 2005-05-15 at 11:13 -0400, Owen Taylor wrote:
> On Sat, 2005-05-14 at 19:37 -0700, Jamey Sharp wrote:
> > 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.
> 
> Thinking about some hypothetical future where Cairo is using XCB
> internally in an application that is using Xlib, it seems like Cairo can
> never rely on the "error event" approach, because the app at best will
> just ignore the unknown event.

I assume you mean that this hypothetical application is using a version
of Xlib that has XCB support compiled in. One piece of that XCB support
involves pulling all events and errors out of XCB's event queue, and
handling them in a manner compatible with Xlib (unless the application
requests that all events and errors be left in XCB's queue). In
particular, errors are passed to the usual Xlib error handler.

XCB keeps errors and events in the same queue simply because that way
their relative order is maintained. That would be a weird notion in Xlib
due to Xlib's callback-oriented error-handling, but XCB doesn't do
callbacks.

> Usually X events an app can receive fall into three categories:
> 
>  - Predictable errors that the app should handle. If I want to 
>    SendEvent to another apps window, that can always fail. If I
>    call SetInputFocus on my own window, that can fail if the window
>    manager unmaps my window.
>    
>    (a fairly common situation ... SetInputFocus, say, is where you
>    need to ignore the error but don't care about whether it occurred
>    or not.)

XCB unfortunately doesn't provide much help with either of these
examples, since those requests don't have replies. I'd take API and
implementation suggestions. Possibly this should be implemented in a
library separate from XCB though; there's certainly enough in XCB's
public API to make that feasible.

>  - Unpredictable errors that indicate more-or-less unrecoverable
>    global failure modes. (connection disconnection and out-of-memory)
> 
>  - Programming errors. (Mismatched depths, or say, you don't handle one
>    of the errors in the first category.)
> 
> Preferably, cairo would handle all errors in the first category,
> set a cairo status on the second class,

I agree...

> and die a noisy death on the third.

Huh. That seems reasonable, except the example of XIOError suggests to
me that giving the application the opportunity to not die noisy deaths
is a good thing.

> > 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. ;-)
> 
> I can't imagine us ever wanting to use XYPixmaps.
> 
> But I don't really don't think Cairo needs anything much from images
> beyond for raw X protocol wrappers ...  we don't need the imutil
> stuff .... GetPixel/PutPixel, because we have libpixman.

Yeah, GetPixel and PutPixel are pretty pointless, at least here.

But when I first wrote the Cairo XCB backend, I copied and pasted code
out of XImage for things like the bits_per_pixel function, and I got
them wrong (Keith fixed them later). The XCBImage code is pretty slim
anyway, and doesn't do much more than I think Cairo actually needs; the
text section is 4K after I chopped out a bunch of "optimizations" that
were in XImage. (It was 7K or so before, as I recall.)

The big thing XCBImage should do (and doesn't at the moment -- we'll get
there) is splitting images if they're too big for the connection's
maximum request size. Currently Cairo on XCB practically requires server
support for BIG-REQUESTS. That's fine for most people, of course, but
seems like a silly limitation.

> Do you need XCBImage to get protocol wrappers for MIT-SHM ?

Nope. They're shipped in libXCB for the moment; eventually the
extensions are supposed to go in separate libraries unless they're used
by XCB internally, like XC-MISC and BIG-REQUESTS. But in any case the
protocol-level stubs are separate from the XCBImage library.

> (But since MIT-SHM isn't used in the Xlib backend either ... there are
> some questions that would have to be answered there. Creating 
> and destroying SHM images on the fly for each cairo_surface_t 
> may be prohibitively expensive, and wipe out the marginal performance
> gains that it gives you. GTK+ actually allocates a big SHM scratch area,
> but there are distinct problems with that as well.)

MIT-SHM's shared pixmaps might be a huge win, though. I dunno how the
server handles them internally, but the ability to do fallback
operations without GetImage/PutImage pairs seems like a good thing. I
seem to recall something similar planned or implemented for the Win32
backend?

> > > +       /* 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.
> 
> The reason why the retry is necessary is that you get an X error if
> you try to GetImage from an off-screen area of a Window. (protocol
> bug, really.) So, a failure from GetImage can't just be ignored.

I don't understand how an immediate retry would help. You can't mean to
spin calling GetImage until the window is moved back on the screen...

> The current code in CVS actually has a hybrid approach ... when 
> copying from a drawable of unknown type it traps errors:
> 
>  ...
> 
> [ quoting code just to indicate that trapping errors in Xlib isn't
>   *that* bad, except for thread-safety issues ]

I'll grant you it's "not terrible". :-) Would you agree the XCB
equivalent is better? (Especially since it's thread-safe?)

> But once it first gets an error it goes through a safe CopyArea/GetImage
> code path. 

Neat. That code seems easy enough to duplicate on XCB.

> There's a nice opportunity for XCB usage in 
> _cairo_xlib_surface_get_size() ...what it want to do is to determine
> A) whether a drawable is a Window B) the current size of a drawable
> in a single round trip. 
> 
> Using Xlib (and not using Xlibint.h) you can do that in a single 
> roundtrip for a Window ... if XGetWindowAttributes() succeeds 
> you've gotten both. But if XGetWindowAttributes gives you BadWindow,
> you need to retry with a separate GetGeometry... two roundtrips.

And two identical GetGeometry requests, since XGetWindowAttributes made
one and threw away its reply... right.

It looks like the XCB backend currently tracks the type of the drawable
across the lifetime of the surface. I guess the new Xlib backend API
eliminated the public window/pixmap distinction?

--Jamey