Re: gtk, to xcb or not

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.


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