(Reply to this)

(Reply to this) (Thread)

(Reply to this) (Parent)(Thread)

(Reply to this) (Parent)(Thread)

I said "eventually", not "quickly". :-) Maybe in ten years. Open source OSes can probably have Xlib-free installs for most users in a couple of years, though, depending on how fast XCB is actually adopted.

There are a variety of advantages to transitioning to XCB listed on the XCB wiki, and I feel any one of them would be sufficient.

For example, replacing the 904kB of text and 16kB of writable data that Xlib maps into memory with 68kB of text and a small fraction of a page of writable data for XCB seems like a very worthwhile win to me.

Consider Alan Coopersmith's blog post where he gives a graphic demonstration of why you should care that we're replacing nasty, complicated, broken thread support with simple, provably correct, and transparent thread safety.

As far as per-request performance goes, you could prove a lower bound on it: it takes a certain number of cpu cycles and syscalls to fill a buffer and write it to a socket. Both Xlib and XCB would be very close to this bound. However, XCB's biggest performance win occurs when you restructure libraries and applications to get work done during round-trip latency. This is impossible with Xlib in general, and is the biggest problem with X network performance once you use 'ssh -CX' to reduce bandwidth usage. See Keith Packard and Jim Gettys' paper, X Window System Network Performance. From the conclusions,

• GetProperty and other inter-client communications mechanisms is a minor problem and might see some relief through asynchronous Xlib interfaces. The Metacity window manager has already demonstrated this technique with favorable results.
• Typically, with current applications based on current toolkits, 10 extensions are initialized, and these typically require at least two round trips before they can be used. ...

For some interesting applications (e.g. Mozilla), a factor of 10 reduction in startup delays due to the network may be possible on broadband links through a combination of compression and latency amelioration techniques.

Many of these improvements would improve performance in the local case as well. Elimination of unneeded round trips reduces context switches. ...

XCB addresses all those latency issues in a general way.

I hope that helps clarify why everyone should be moving to XCB. :-)

(Reply to this) (Parent)(Thread)

(Reply to this) (Parent)(Thread)

Xlib gets smaller when you rip out the part that XCB directly replaces, but you're right: that combined with XCB is a little bit larger. Compiling my checkout of Xlib --without-xcb gives:

   text    data     bss     dec     hex filename
 947415   15260    1484  964159   eb63f .libs/libX11.so

Compiling --with-xcb, and looking at the size of XCB itself, gives:

   text    data     bss     dec     hex filename
 922622   14696    1484  938802   e5332 /usr/local/lib/libX11.so
  67020     780      68   67868   1091c /usr/local/lib/libXCB.so

So the combined text sections are 42kB bigger. There's protocol-layer code redundancy between Xlib and XCB still, and we could probably eliminate the size difference by rewriting all the Xlib protocol stubs to call XCB. Doing so could very well make the pair of libraries smaller than the original. However, that involves working on a library that we want people to just quit using anyway... :-)

In short, I was only trying to say that if you completely migrate from Xlib to XCB, there's a substantial disk and memory savings. I wasn't trying to claim anything about the intermediate steps.

(Reply to this) (Parent)