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

[Owen Taylor]

On Sun, 2005-05-15 at 12:14 -0700, Jamey Sharp wrote:
> 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.

Two problems with this occur to me:

 - if I make a request (without a reply, say), it seems that an Error
   reply could be processed out of the event queue by another thread
   before I had a chance to do anything about it. 
 
 - If I'm mixing libraries together, I have no real way of getting
   a callback for a delivered event ... so I can't find out when
   an Error occurs for a request I make.

If I make a request, I "own" that request, and I should have some
mechanism for getting a first crack at the reply. Callbacks are an
obvious way of doing that, and really the only sensible  way to do thing
in a single-threaded app. 

Another way of doing things, which fits in closer to the XCB current
model would be to have some way of executing requests and directing
errors to a "secondary event queue". 

(A bit like a Java ReferenceQueue:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/ReferenceQueue.html,
used by WeakReference and friends:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html)

This just allows batching, not asynchronicity for a single-threaded
app but is general for a multi-threaded app.

> > 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.

See above.
 
> >  - 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.

XIOError is the second category. I don't think apps can meaningfully
recover from a programming error. What does that even mean? But noisily
setting a Cairo status could work too.

> > > 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.)

Extra shared library dependencies are actually pretty costly ... vastly
more so than extra code in an existing library. (ELF symbol lookups
involve a linear scan in the list of open libraries, more or less.)
So, shared libraries with 4k of text are pretty discouraged.

[...]

> > (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?

If you are *mixing* client side and server side rendering, then a 
ShmPixmap is a big win. If you are rendering only client side, then
it's just a small win. And in the cases where we could use a ShmPixmap
for the surface (when we create the surface ourselves), we can just as
well create an image surface and do the rendering there.

> > > > +       /* 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...

I'd really advise you to read the Xlib backend code ... it's going
to be a clearer explanation than I can give here. But basically, 
CopyArea to a pixmap, and GetImage from the pixmap allows you to
get the onscreen area with the offscreen area undefined, which was
you wanted originally.

> > 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 snce it's thread-safe?)

Yes, certainly. When you want to do advanced stuff (trap errors, 
combine multiple operations), XCB should be a lot better.

> > 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?

Yes, Carl convinced me that the backend should determine Window vs.
Pixmap itself. It's marginally less efficient in a couple of ways,
but mostly in unusual and avoidable circumstances.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050515/c91240f9/attachment.pgp