[Xcb] Re: gtk, to xcb or not

[Yang JianJun]

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

On 11/10/06, Jamey Sharp <jamey at minilop.net> wrote:
>
> 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
> gtk-devel-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xcb/attachments/20061110/c1794ef6/attachment.html