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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx - > 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@xxxxxxxxxxxxxxx - http://go.to/ibaldo > > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
