Hi Bart, I have used oprofile to test the performance both gtk-xcb and gtk-x11, and replied all the information to you, but it seems the mail haven't arrived to the archive. I also CCed it to <a href="mailto:gtk-devel-list@gnome.org"> gtk-devel-list@gnome.org</a>, so you can get it at <a href="http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00035.html">http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00035.html</a> --Jianjun <div>On 11/8/06, Barton C Massey <<a href="mailto:bart@cs.pdx.edu">bart@cs.pdx.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This is terrific news! We will definitely try to help you look at the bugs, although it will probably be next week rather than this one for me at least. Can you give us more details about the performance difference?  Even if your numbers aren't solid, they let us know the impacts and where to look for optimizations. Thanks much!     Bart Massey     Assoc. Prof. Computer Science     Portland State University     <a href="mailto:bart@cs.pdx.edu">bart@cs.pdx.edu</a> In message <<a href="mailto:934b4cdf0611070419q51ffb9c9v18f430883c79b5fc@mail.gmail.com">934b4cdf0611070419q51ffb9c9v18f430883c79b5fc@mail.gmail.com </a>> you wrote: > --===============1611316647== > Content-Type: multipart/alternative; >       boundary="----=_Part_3287_26332206.1162901941431" > > ------=_Part_3287_26332206.1162901941431 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > I am always working on the xcb port of gtk. So far most common gtk > applications can run well atop the gdk-xcb backend. As the dependency of > gtk, Pango and Xft are ported as well. > > These XCB backends are built on the 1.0 RC3 (0.9.93) release of xcb-proto > and libxcb(<a href="http://xcb.freedesktop.org/dist/">http://xcb.freedesktop.org/dist/</a>), as well as the latest > development version of xcb-util(git://anongit.freedesktop.org/git/xcb/util). > Maybe the utility libraries are unstable, but I have employed it. > > These XCB backends are not built by default, and you must explicitly use the > configuration option: >  * Xft: --enable-xcb >  * pango: --enable-xcb >  * gtk: --with-gdktarget=xcb > > You can get all my xcb-porting work from  " > <a href="http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/">http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/</a>" , then try to build > them. If all works well, you can get <a href="http://libgtk-xcb-2.0.so">libgtk-xcb-2.0.so</a> and > libgdk-xcb-2.0.sofinally. > > GTK-XCB is now entirely XCB based, claiming the full benefits of XCB. I have > not taken codes sharing into account between the two X backends, perhaps it > brings a huge maintenance burden, maintaining two copies of that that differ > only in their interface to the X protocol. > > I have used gtkperf to test the gdk-xcb performance on PC, but the benchmark > data shows gdk-xcb is a bit slow than gdk-x11 :( > > Followings are the next steps : > > * event handling > There is still a bug in window redraw. Originally the area in window does > redraw when its window content is fully visible after the overlapping window > disappear. But if you repeat to  make the window partially obscured, and > fully visible many times, the area then does not redraw any more. > > * error handling. > Build a library atop libxcb to provide such functions as XSetErrorHandler > and XSetIOErrorHandler. > > * Key handling. > Rewrite XKeysymToString and XStringToKeysym in a library built on XCB, to > provide the transformation between keyname and keyvalue. > > * GC contents caches > XCB does not cache the GC contents on client-side. Maybe should I cache the > gc values in gdk-xcb backend to implement gdk_gc_get_values? > Anyway, I'd appreciate any advice/pointers you could provide, poking at the > gdk-xcb backends. > > Jianjun > > ------=_Part_3287_26332206.1162901941431 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > <div>&nbsp;</div> > <div>I am always working on the xcb port of gtk. So far most common gtk applications can run well atop the gdk-xcb backend. As the dependency of gtk, Pango and Xft are ported as well.</div> > These XCB backends are built on the 1.0 RC3 (0.9.93) release of xcb-proto and libxcb(<a href="<a href="http://xcb.freedesktop.org/dist/">http://xcb.freedesktop.org/dist/</a>"><a href="http://xcb.freedesktop.org/dist/"> http://xcb.freedesktop.org/dist/</a></a>), as well as the latest development version of xcb-util(git://anongit.freedesktop.org/git/xcb/util). Maybe the utility libraries are unstable, but I have employed it. > > These XCB backends are not built by default, and you must explicitly use the configuration option: &nbsp;* Xft:&nbsp;--enable-xcb &nbsp;* pango:&nbsp;--enable-xcb &nbsp;* gtk:&nbsp;--with-gdktarget=xcb > You can get all my xcb-porting work from&nbsp; &quot;<a href="<a href="http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/">http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/</a>"> <a href="http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/">http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/</a></a>&quot; , then try to build them. If all works well, you can get > <a href="<a href="http://libgtk-xcb-2.0.so"> http://libgtk-xcb-2.0.so</a>"><a href="http://libgtk-xcb-2.0.so">libgtk-xcb-2.0.so</a></a> and <a href="<a href="http://libgdk-xcb-2.0.so">http://libgdk-xcb-2.0.so</a>"><a href="http://libgdk-xcb-2.0.so"> libgdk-xcb-2.0.so</a></a> finally. > GTK-XCB is now entirely XCB based, claiming the full benefits of XCB. I have not taken codes sharing into account between the two X backends, perhaps it brings a huge maintenance burden, maintaining two copies of that that differ only in their interface to the X protocol. > > I have used gtkperf to test the gdk-xcb performance on PC, but the benchmark data shows gdk-xcb is a bit slow than gdk-x11 :( > Followings are the next steps : > * event handling There is still a bug in window redraw. Originally the area in window does redraw when its window content is fully visible after the overlapping window disappear. But if you repeat to&nbsp; make the window partially obscured, and&nbsp; fully visible many times, the area then does not redraw any more. > > * error handling. Build a library atop libxcb to provide such functions as XSetErrorHandler and XSetIOErrorHandler. > * Key handling.&nbsp; Rewrite XKeysymToString and XStringToKeysym in a library built on XCB, to provide the transformation between keyname and keyvalue. > * GC contents caches XCB does not cache the GC contents on client-side. Maybe should I cache the gc values in gdk-xcb backend to implement gdk_gc_get_values? > <div>Anyway, I'd appreciate any advice/pointers you could provide, poking at the gdk-xcb backends.</div> > <div>&nbsp;</div> > <div>Jianjun &nbsp;</div> > > ------=_Part_3287_26332206.1162901941431-- > > --===============1611316647== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Xcb mailing list > <a href="mailto:Xcb@lists.freedesktop.org"> Xcb@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/xcb">http://lists.freedesktop.org/mailman/listinfo/xcb</a> > --===============1611316647==-- </blockquote></div>