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 - [EMAIL PROTECTED] - 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: [EMAIL PROTECTED] - http://go.to/ibaldo _______________________________________________ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list