Re: (severe) performance issues

["David J. Andruczyk" <djandruczyk yahoo com>]

I do this already ahead of time . I ONLY update the labels when
absolutely necessary..

As a workaround I moved t GTKEntries which did NOT have the
performance problem,  though I can't quite make them appear like a
GtkLabel in all instances, since there is NO  other wisget that can
be used to display rapidlychanging text. (it's a textual display
for a realtime datalogger, so fast updating is wanted)

I have managed in some themes to get the entry's background color
to change to that of it's parent,  but in some themes the colors
don't match and I end up with a different colored rectangle around
the text. (which I can live with for the time being as the cpu
usage dropped from 45% (on a 2.1Ghz machine) down to 4% by changing
from GtkLabels to GtkEntries..


--- Ivan Baldo <ibaldo adinet com uy> wrote:

>   Hello.
> 
> El 29/03/07 12:26, Paul Davis escribió:
> > this is a sort of known "bug". setting the text of a label
> causes a
> > recompute of the label's size, which can propagate up the
> containing
> > widget tree. add Pango into the mix, and that resetting is very
> costly. 
> > the same is not true of text entries, because they never resize
> based on
> > their contents.
> >
> > evolution, sodipodi (the precursor to inkscape) and a few other
> projects
> > have implimented their own labels that do not do this, for
> precisely the
> > reason you are now discovering.
> >   
> I don't know if this applies to the original person with the
> problem, 
> but there is a simple optimization for when an application
> repeatedly 
> sets the same text to the label.
> In gtk_label_set_text and gtk_label_set_label a simple strcmp of
> the str 
> argument against the label or text fields of the label structure
> can 
> avoid all re-computations and mallocs and frees when the text
> specified 
> is the same as the previously one.
> 
> In my case, I write applications in a very dumb way, I expect
> that GTK 
> detects such silly things and avoid computations when it can.
> For example in a current application that I am working I set
> values for 
> a group of spinbuttons when only one changes, so I set all the
> values to 
> the previously set ones and only change one.
> Doing it in a smarter way means I need to put more time on it,
> slowing 
> the true advancement of the application. Luckily it seems that 
> gtk_spinbutton_set_value checks that the value has really changed
> and 
> avoid expensive operations if it doesn't.
> I expect the same behavior in all GTK facilities, helping the
> user when 
> it is reasonable and easy to do.
> 
> In gtk_label_size_request there is code to get the desired width
> and 
> height of the label, that could be called on the set_text and
> set_label 
> functions to see if they differ to the current allocated ones by
> a 
> threshold, and only then call gtk_widget_queue_resize_no_redraw 
> (expensive?) and always do a redraw (since the text is different
> so 
> something has changed).
> 
> I am not an expert on GTK so I am really shy to try to implement
> this, 
> benchmark it, test it, etc. since I don't understand it fully...
> Also because of that, maybe this email is totally wrong, I may be
> 
> misunderstanding everything :).
> 
> Goodbye.
> 
> -- 
> Ivan Baldo - ibaldo adinet com uy -
> http://ibaldo.codigolibre.net/
> ICQ 10215364 - Phone/FAX (598) (2) 613 3223.
> Caldas 1781, Malvin, Montevideo, Uruguay, South America.
> We believe that we are free, but in reality we are not! Are we?
> Alternatives: ibaldo codigolibre net - http://go.to/ibaldo
> 
> 
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
> 


-- David J. Andruczyk


 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather