Re: Porting GDK to use XCB on the backend

[Mike Emmel <mike emmel gmail com>]

On 6/22/05, Owen Taylor <otaylor redhat com> wrote:
> On Tue, 2005-06-21 at 16:25 -0700, Travis Spencer wrote:
> > Hey All,
> >
> > I am taking Open Source Software as an undergrad this term from Bart
> > Massey at PSU [1].  One of the projects that I'm seriously considering
> > working on is porting GDK to use XCB on the backend.  With the help
> > of Bart (one of the creators of XCB) and Jamey Sharp (XCB's primary
> > coder, implementer, co-creator, and fellow PSU student), I'm sure I
> > could make a real dent in this.
> >
> > I know that Christian Neumair asked about this a year ago [2], but I
> > haven't seen any work done on it or much talk either.  Am I
> > overlooking something or has the job still not been started?
> >
> > In the post reference above and elsewhere [3], Owen suggested porting
> > gdkasync.c to XCB without changing any of the other code in GTK+.  Is
> > this still a good place to start?  What is so significant about
> > gdkasync.c?
> 
> Note to start off with that for compatibility reasons, GTK+ needs to
> keep linking to Xlib and exporting gdkx.h. This means that making GTK+
> use XCB is something that can only done within the context of an Xlib
> that uses XCB internals.
> 
> It would be possible to do an XCB backend from GTK+ that is independent
> from the current Xlib backend and doesn't try to present compatibility,
> but that's clearly a bad idea for the desktop. For something like
> an embedded device, it might be more interesting: a way of cutting
> out some of the bulk of Xlib, but there is a huge maintenance burden
> there: the Xlib backend is 32,000+ lines of code - maintaining two
> copies of that that differ only in their interface to the X protocol
> doesn't sound like any fun.
> 

Its my understanding that the issue of Xlib/xcb compatibility has been
solved there exists some sort of xlib on xcb library or at least proof
of concept. I think this approach if it exists our could be built
would solve the migration and support problems. Anything to kill xlib
is good stuff IMHO :)

Mike

> gdkasync.c is interesting because it is code that can actually take
> advantage of XCB. It's using Xlib "internals" in order to reduce
> round-trips to the X server. This works OK, other than some thread
> safety problems, but it is very messy. XCB (with some improvements)
> could be used to do this in a much cleaner way.
> 
> Another nice thing about gdkasync.c is that it would be easy to have
> a conditionally compiled gdkasync-xcb.c that was used only when
> GTK+ was compiled against an Xlib with XCB internals.
> 
> Regards,
>                                                 Owen
> 
> 
> 
> BodyID:89884073.2.n.logpart (stored separately)
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
> 
>