Re: (severe) performance issues
- From: Paul Davis <paul linuxaudiosystems com>
- To: "David J. Andruczyk" <djandruczyk yahoo com>
- Cc: gtk-list gnome org
- Subject: Re: (severe) performance issues
- Date: Thu, 29 Mar 2007 11:26:39 -0400
On Mon, 2007-03-26 at 17:17 -0700, David J. Andruczyk wrote:
> I hadn't tried that as I assumed that it was off by default unless
> enabled..
>
> Since a simple test program doesn't show it,. but my app does and
> the performance hogging goes away when I comment out one line
> (gtk_label_set_text) the problem appears to be internal to GTK>
> Another fine fellow suggested it may be due to resizing of widgets
> caused by the label update, and showed me a way to set it to a
> fixed size, but that ahd no effect on cpu usage (still high).
>
> I managed to create a workaround by useing a GtkEntry instead, and
> working out some trickery to make the entrie's background color
> (normally white) to match it's parent so it blends in and looks
> like a label, and presto, cpu usage went from 40-45% down to 4 %.
>
> For some reason in my case the label updates seem to be triggering
> some internal stuff for no good reason. when I get a little time
> I'll try to extract that section of code int oan isolated test
> case, and if it still shows that I'll file it as a GTK+ bug.
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 would have replied sooner, but was away in berlin at the linux audio
conference with no email access or time)
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]