[Xcb] Re: [Xlibs] Quick XCL, implemented

[Jim Gettys]

What can I say?  Wonderful!

Keep up the dynamite work!
                         - Jim

On Sun, 2003-11-02 at 03:13, Jamey Sharp wrote:
> 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
> http://freedesktop.org/~jamey/X11-xcb-1.patch.
> 
> 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
> =6486 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...
-- 
Jim Gettys <Jim.Gettys@hp.com>
HP Labs, Cambridge Research Laboratory