Performance change from X in Fedora Core 4 to Fedora Core 5
Carl Worth
cworth at cworth.org
Tue Jul 11 15:55:45 PDT 2006
On Sun, 09 Jul 2006 13:56:27 +0100, Roo wrote:
> I strongly
> suspect the introduction of Cairo (and the change to GTK to use it
> exclusively), but obviously I can't prove that since there is no facility
> to tell GTK not to use Cairo and test it.
There has been a lot of speculation that any performance problems in
GTK+ as of version 2.8 are greater are all due to GTK+'s use of cairo.
Speculation alone is useless, but as you hint, what could make it
useful is a way to measure things.
As mentioned in this thread already, there was a GNOME performance BOF
at GUADEC recently, and one of the things that came of that was a
series of patches from Matthias Clasen to revert uses of cairo within
GTK+ to the pre-cairo behavior.
For example, there is this one:
http://mail.gnome.org/archives/performance-list/2006-July/msg00000.html
Matthias, did the earlier patch never make it to the list? I'm not
seeing it in the archives.
If you have good luck with any of those patches then I will be very
interested in hearing about it, as it would definitively identify a
performance problem in cairo, (the X server could perhaps be blamed as
well---but conceivably, cairo could work around any X server slowness
by using whatever X server functionality GTK+ was using prior to
calling into cairo[*]).
> Performance is the elephant in the room when it comes to GTK... so
> discussing it with GTK developers is a pointless task.
There's useful work being done by GTK+ developers on the GNOME
performance-list. Subscription information is available here:
http://mail.gnome.org/mailman/listinfo/performance-list
Feel free to follow up there with any reports on trying out the
de-cairoification patches for GTK+.
-Carl
[*] That kind of work can be done to avoid performance regressions,
but it is a bit tricky as it might also prevent future performance
optimizations. Getting the right balance inside cairo is hard as the X
server doesn't do a very good job of advertising which operations are
"fast" and which are not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060711/983523e9/attachment.pgp>
More information about the xorg
mailing list