[Xcb] Quick XCL, implemented

Jamey Sharp jamey@cs.pdx.edu
Sun, 2 Nov 2003 00:13:57 -0800

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I've got almost every Xlib app I've tested running on top of XCB now,
without relinking.

Heh. Wow.

Mozilla is the only completely broken exception I've seen. Keith had
suggested it might be using a custom threads library, which wouldn't
work alongside XCB since XCB uses pthreads only. Everything else looks
like it's running correctly, though I fairly frequently get "Xlib:
sequence lost" messages. I'm hoping somebody will help me fix that.

The implementation strategy was to replace anything that used Xtrans
with calls to XCB. This affected XlibInt.c, OpenDis.c, and ClDisplay.c,
and meant I could remove x11_trans.[ch], ConnDis.c, and Xintconn.h. So
far, I believe my changes are entirely binary compatible with existing
extensions, not to mention applications. The patch is at

Cool statistics: Between lines added/removed directly in Xlib source and
relevant lines in XCB and Xtrans (...um, #include'ing source files is
evil?), this patch cuts a lot of lines of code from Xlib:
-3097 in X11
+ 322 in X11
+1803 in XCB
-5514 in Xtrans
=3D6486 lines saved, roughly.

It seems to have cut 25kB from libX11.so (according to the 'dec' column
of output from size), which is almost disappointing since XCB is 25kB.
On the other hand, 19kB of XCB is core protocol implementation, and
we'll save close to 130kB when we replace Xlib's core protocol code with
glue to XCB.

This work doesn't yet meet the goals of XCL, as I don't think calls to
Xlib and XCB can be mixed. I haven't tested that it doesn't work, but
there's no reason it should, and I can promise that mixing calls to the
two event queues will have undesired results. I've accomplished some
other things instead.

This change is good for Xlib. Thousands of lines of scary, complicated
code disappear. XCB accomplishes the same things as Xlib at this level,
yet its internals are much simpler. A recent patch to XlibInt.c to fix
weird signedness issues that are difficult to reproduce... just goes
away. This puts us in a good position to convince ourselves of the
correctness of the code, using formal methods where appropriate, and
Bart has done some of this for XCB already.

This change is good for XCB too. Obviously this is a big change to Xlib
and needs a lot of testing before inflicting on anyone but the bravest
developers. But to this point XCB has been difficult to test-- and
offered little incentive to do so-- due to a complete lack of real
applications written for it, and now all Xlib apps are test cases for
XCB too. Among other current XCB problems, the only platform I actually
expect XCB to work on is Debian GNU/Linux, 'testing' distribution or
later, on i386. I just discovered today that there were warnings under
gcc 2.95 that I never noticed since I'm using gcc 3.3, and we know it
fails to run on Sparc Solaris. Letting Xlib use XCB instantly offers
plenty of test apps and plenty of incentive to do the testing.

For these reasons, I'm hoping that people who know X better than I do
will see that this is an important time to get involved in the
development and testing of XCB.

What's next? There's a little more work needed to make mixed calls to
Xlib and XCB work, and this may break binary compatibility with
extensions (but it might not, and anyway we don't care). That's
necessary for any closer integration of XCB into Xlib. There's also a
need for testing and debugging XCB on as many platforms as we can get
ahold of. (I saw a VAX emulator around recently, though I'm not sure how
good its pthreads support is...)

Feedback and testing would be welcome. Thanks...
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (GNU/Linux)