RE: so, is this claim about pango still true? or does nobody actually care?

["Robert Thorpe" <Robert Thorpe antenova com>]

> -----Original Message-----
> From: gtk-list-bounces gnome org 
> [mailto:gtk-list-bounces gnome org] On Behalf Of Paul Davis
> Sent: 14 October 2005 04:30
> To: gtk-list gnome org
> Subject: so,is this claim about pango still true? or does 
> nobody actually care?
> 
> We are about 60% of the way through porting Ardour, probably 
> the premier digital audio workstation for Linux (winner of 
> Linux Journal's Best Project prize for 2005, and other 
> awards) from GTK1 to GTK2. Today, someone sent me this email:
> 
> ------
> sorry to bug you directly, but I caught a post of yours on 
> slashdot regarding ardour being ported to GTK=2.x  I did that 
> to some of my apps and hit several things that may cause you 
> problems.  Teh main thing is it's about 3-12x slower, and 
> text rendering is the primary problem. (the main fault isn't 
> necessarily in
> GTK+ (though it IS slower and more bloated in the 2.x trees) it's with
> Pango. 
> IF you have any fields that need to render text and change it 
> often, you'll find that it consumes and exhorbitant amount of 
> CPU.  I've traced this issue in my own code. (not nearly 
> complex as anything like ardour) and pango was the culprit, 
> bugs were filed and fell on deaf ears (owen taylor) and 
> nothing has been done over the past 3 years.  I've since 
> decided that QT-4 was a better route. (requires a LOT of work 
> for me,  but in the end the gui will be far more flexible and 
> faster, and much easier for me to run on multiple platforms 
> including win32)
> 
> Just thought you'd want to know that there are some 
> significant performance concerns on GTK+-2.x.  As a reference 
> the perf issue I was having was most evident when updating a 
> textual label (reporting some ADC value) at a rapid rate (10x 
> per second or so).  Updating 5-10 labels at h the above rate 
> (this was reporting data for an outside slow-speed data 
> acquisition system) resulted in cpu usage of over 40-60% on a 
> 1200 mhz processor.  All other major functions were disabled 
> in the program to make 100% sure that the text rendering was 
> causing the problems.  gprof'ing the executable pointed to 
> calls in pango (a large number of them eating a little for 
> each function, but that added up to horrible performance).  
> GTK+-1.x doesn't have this issue as it used core
> X11
> fonts and that is screaming fast.  QT doesn't use pango it 
> uses somethign else but it didn't seem to show any 
> appreciable cpu usage for a similar application..
> -----------------
> 
> is this still true? does anybody care? is there a way to 
> avoid pango entirely and still get AA fonts inside GTK2? will 
> this ever be fixed before everyone is using h/w acceleration 
> to print button labels?
> 
> the issue raised here will *kill* ardour dead, and would 
> force us to also have to abandon GTK for Qt (a move I would 
> really, really not want to make). some clarification would help ....

I don't know if the above is all true, but some of it is.  I've 
been given various advice by people here on speeding up GTK+ 
applications that may be useful to you.  I haven't tested them 
properly yet: -

* Text measurement in XaW is free, it is not in GTK+.  Do not 
re-layout text assuming it is.

* Disable double buffering if you don't need it with:
gtk_widget_set_double_buffered()
(may help, may cause flickering)

* If you have to, use gdk_draw_string to bypass Pango, or
bypass it by calling X.

GTK+ certainly won't work very well on an original Pentium.
GTK+ developers see the library as being primarily for fast 
machines.