Hi Jamey, Thanks for all the information! But I am just wondering whether I need to continue the entirely xcb-based Gtk-XCB backend. If necessary, I would like you to have a glance at my code,  and any comments would be appreciated. In addition, I will try to make gdk_window_queue just to iterate the main event queue. Best Regards, Jianjun <div>On 11/10/06, Jamey Sharp < <a href="mailto:jamey@minilop.net">jamey@minilop.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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. :-) --Jamey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFVAo3p1aplQ4I9mURAlOQAJ9Y2WF8tkLH3vZrt/5gkJO3UzhH/wCfXbqz tftHwJ9Ppd3ySGboqpExoWU= =QfvK -----END PGP SIGNATURE----- _______________________________________________ gtk-devel-list mailing list <a href="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org </a> <a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a> </blockquote></div>