Re: gtk, to xcb or not

On Thu, Nov 09, 2006 at 10:20:53PM -0500, Havoc Pennington wrote:
> Jamey Sharp wrote:
> > Assuming a project is willing to require the new version of Xlib, then
> > avoiding dual-maintenance hell is easy. The Xlib-specific interfaces (in
> > this case, gdkx.h) can still be provided; they become simple wrappers
> > that first convert Xlib types to XCB types with help from libX11-xcb,
> > then call into the XCB version of the same code. [1]
> If I understand what you're saying, the Xlib wrapper around XCB is 
> mostly source compatible with Xlib but not fully source compatible and 
> by no means ABI compatible?

No, I'm not saying that at all. It's fully backwards-compatible in both
API and ABI. However, to take advantage of the new features, you have to
use a couple of functions that obviously don't exist in previous
versions of Xlib -- namely, XGetXCBConnection and XSetEventQueueOwner.

> The wrapper doesn't give a way to keep gtk-x11 ABI compatible, though, 
> that I see... ?
> As an example, to keep GTK's ABI guarantees/policy, metacity would have 
> to keep working without recompilation ... and metacity uses Xlibint.h.
> So keeping the ABI while cutting to XCB is tough...

Obviously, such apps must continue to link against Xlib/XCB, which
provides full ABI compatibility even for Xlibint.h. This is why X
extensions (which all use Xlibint.h) continue to work when you drop in
the new, XCB-dependent version of Xlib in place of a traditional
implementation. No apps or libraries need to be relinked: I'm running
stock Debian testing against this XCB-capable Xlib right now.

> The viable approaches I can think of:
> 1) "cut and run" or "the GTK 1.2 approach" which is basically just leave 
> the old library ABI compatible and completely untouched for the next 10 
> years - avoid maintenance burden by not doing any maintenance.

If the Gtk+ developers are OK with this, I'm all for it. Making Xlib go
away as fast as possible is fine with me. :-) But I don't think you
actually have to go there: we've tried hard to ensure that ABI
compatibility is not that difficult.

> 2) keep one codebase for gdk-xcb and gdk-x11 (which would be most easily 
> done by pretty much using the xlib API perhaps, but in any case some 
> kind of abstraction layer perhaps with some simple #ifdef'ing). Build 
> the same codebase twice when building gdk, once linking it to X11 and 
> once linking it to XCB. Apps using this gdk-xcb could just use XCB 
> directly even though gdk itself would have the shim layer.

The approach I outlined earlier is neither of these, and I think is
better than #2. I'm not sure how to make it more clear though; perhaps
my earlier mail will make more sense with the above explanations?

> The first thing though is probably to step back and ask if it's all 
> worth it ...

It's definitely a good question for any substantial change. My opinion
is that XCB is fundamentally a better architecture and a better API, and
that the change is worthwhile from a software engineering perspective
even if you're right that there's no performance advantage.

But I believe you'll find you can at least make app startup quite a bit
faster on high-latency links -- correct me if I'm wrong, but I haven't
seen any signs that Gtk+ and its dependent libraries have made as much
progress as you can easily make with XCB. At the least, Xlib has three
useless round-trips in XOpenDisplay that you can't eliminate without
breaking the ABI, and I suspect that few apps should need more than,
say, five round trips to put up a window and have all resources ready.
It looks to me like gnome-terminal still does more than thirty round
trips before it starts drawing, not even taking advantage of existing
Xlib APIs for combining InternAtom round-trips. (This is from a couple
minutes poking around with wireshark, and may not reflect reality in any
way. But it at least isn't obviously doing the right thing yet.)

I also hope you'll see the libraries above and below Gtk+ migrating to
XCB, in which case there will be increasing benefits to using purely XCB
throughout the entire stack.

> Smaller memory footprint is one advantage worth investigating.

A complete migration to XCB certainly buys you that and smaller disk
footprint, yes. :-)


Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]