[Xcb] gtk-xcb performance profiling
Vincent Torri
vtorri at univ-evry.fr
Wed Nov 8 07:29:35 PST 2006
have you tried :
XLIBBUFFERSIZE=4 gtkperf
?
It sets the size of the Xlib cache to 4 KB. You should see a decrease of
the speed of the Xlib-based gtk. Then, that speed should be closer to the
one of XCB-based gtk
Vincent
On Wed, 8 Nov 2006, Yang JianJun 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==--
>>
>
> --
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> Message délivré par le serveur de messagerie de l'Université d'Evry.
>
>
More information about the Xcb
mailing list