Re: (severe) performance issues


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 :).


Ivan Baldo - ibaldo adinet com uy -
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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]