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