Re: gtk, to xcb or not

[Havoc Pennington <hp redhat com>]

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?

If so, then for the next ~10 years or more everyone will still be 
shipping a GTK ABI that links to libX11.

A mostly-source-compatible wrapper helps quickly port apps that use 
gdkx.h extensively (mostly weird apps, like metacity or the pager 
applet). Those are the same apps that might actually benefit from XCB, 
so once the desktop is up-and-running on the Xlib-like shim, you might 
hope for a moderately quick move away from it.

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...

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.

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 first thing though is probably to step back and ask if it's all 
worth it - GDK/GTK already are pretty good about avoiding round trips, 
for example, and they will never be threadsafe anyhow. I'm guessing X11 
vs. XCB won't show up in profiles too much for GTK because the big X 
issue in profiles is round trips, and if there aren't any that XCB helps 
kill off, it just won't matter... the time is all going to be in things 
like Cairo and GObject, not in the X stuff.

Smaller memory footprint is one advantage worth investigating.

Also worth investigating is whether there would be noticeable wins in 
the desktop that uses gtk, e.g. metacity (well, maybe only compiz 
matters now), or the pager. The pager is suffering from libwnck being a 
crazy lot of crack though anyhow, and metacity already has asynchronous 
property fetching and there just aren't a lot of other round trips 
involved in a WM ... you could kill synchronous error traps from 
metacity probably, but I don't know how much that would matter.

Havoc