[Glade-users] Glade performance unbearably slow

[tristanvb at openismus.com (Tristan Van Berkom)]

On Thu, 2011-12-08 at 12:19 +0100, Matej Nanut wrote:
>         If you resize the main window, or better yet, just resize the
>         window
>         pane that contains the property editor (showing more/less of
>         the
>         workspace), do you find that displaying the properties is
>         exceedingly
>         slow ?
>         
>         Do the entries 'chop' alot or do they resize smoothly while
>         you
>         drag the window pane ?
>  
> They definitely "chop" more if I have a GtkWindow selected, compared
> to a GtkBox, for example. But they aren't abnormally slow. I don't
> have to sit back and wait for it to refresh or anything, like I have
> to when selecting a widget.
>
> So the process of building a properties pane is doing this? It makes
> sense, considering the slow-down not happening when I choose a widget
> of the same type.

Not building it, just even displaying it.

Since you say that selecting a different widget type, after having
already selected that type once causes lag, as opposed to say,
selecting two widgets of the same type.

The editors are indeed cached, they are even all added to the
same box inside the editor widget (we just show/hide them inside
that box, which has proven to be quicker than doing
gtk_container_add/remove()).

> If GTK is the culprit, what are my options? Switch to Qt? >_<

Well, GTK+3 size requesting process is slightly more heavy
than GTK+2 was, but should really not cost more than
2 or 2.5 times more time (since width is requested separately
from height and we have some extra passes going on).

However I'm sure there is something that is not justified
in your scenario, it could have to do with drawing the widgets
for the first time, or that combined with requesting them.

In any case, the size requesting code in GTK+3 is not
even one year old in a production release, it's still
very young code.

Im sure with some help, profiling, we can nail the issues
at hand an no-one will have to get all dramatic and
"switch to QT" ;-)

Of course, that is the nature of a real community run
project, I suppose if people are not willing to actually
participate in the development of the toolkits that they
use, they might as well chose a commercial toolkit and
pay a license fee instead...

Cheers,
       -Tristan