[Xcb] cairo + xcb binaries

[Barton C Massey]

In message <493E3801.4040700 at codewiz.org> you wrote:
> FWIW, Fedora is not enabling the xcb backend because
> apparently it changes the ABI of libcairo.so:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=465759
> 
> This prevents the window manager Awesome from appearing in
> Fedora 10.
  
Thanks much for the pointer!  It turns out that "changing
the ABI" isn't the real problem---it's that there's no
current version of the XCB backend, period.  We really need
to find an XCB developer willing to upgrade and maintain the
Cairo backend; that may have to be me or one of my students.
I just had a long conversation with Carl about it.

> I don't see a big rush to XCB among the toolkit folks yet.

The toolkit folks are moving atop Cairo, Pango, etc so as
these things go so goes XCB, I think.  Matthew's problem
here needs to be addressed so that we can move forward
seamlessly.

> Maybe some benchmarks showing how XCB would improve
> throughput or latency would help convince people?  If
> there's any evidence you could share, I'd be interested in
> seeing them.

XCB isn't about improving throughput per se; X11 throughput
is already just fine unless round trips (engendering
latency) are involved.  XCB's latency is dramatically better
than Xlib's in some cases, but only if programmers take
advantage of its latency-hiding features by delaying forcing
of cookies or by writing multithreaded code.  Just
transliterating Xlib code won't cause any change in latency.

Among XCB's intended advantages are simplicity,
controllability, ease of extension, ability to work
seamlessly in threaded clients, ability to hide round-trip
latency in situations where it impairs performance, and all
the advantages of working from explicit protocol
descriptions.

Making XCB act as an improved transport for stock Xlib is
something that we needed to do to permit a gradual
transition from Xlib to XCB, and something that has fixed
quite a few Xlib bugs (and introduced a couple :-).  It was
never where we intended to go, and is interesting to us
mostly because of the problems it causes.

> For now, most distros ship an XCB enabled version of
> libX11, which made some things slightly slower, iirc.

It has been a long time since we measured.  However, it was
rarely more than a few percent on real apps, and I suspect
the latest round of magic (plus increasing the buffer size :-)
has actually made most of that go away.

> A comparison against new version of libX11 would be a bit
> unfair.

I don't understand?  If you mean that comparing Xlib/XCB
performance against XCB performance would be unfair, maybe
somewhat. Xlib does dodge much of XCB's implementation, so
we sometimes do these kinds of comparisons to help diagnose
performance issues in XCB's top half.

In any case, I don't know anyone who works inside Xlib
who...no, I'll just stop.  I don't know anyone except Jamey
and Josh who works inside Xlib. :-) So it's pretty likely
that Xlib/XCB will be the permanent state of the Xorg bits,
making any performance comparison against a system we'll
never see again kind of irrelevant.  If there are actual
performance *problems* in XCB or in Xlib/XCB, we of course
want to diagnose and fix those.

    Bart Massey
    bart at cs.pdx.edu