GNOME.org
 

[Glade-users] [glade-users] Glade 3.10.0 is running a bit slow

On Wed, Dec 28, 2011 at 12:59 AM, Micah Carrick <micah at quixotix.com> wrote:

Well I should first point out that my 2 second lag is more like 1 second
now--not quite sure why.

With the patch (I pulled master 4 or 5 days ago) I don't see
any?noticeable?difference. I'm testing with a GtkBox with a GtkButton and
GtkLabel as the children and clicking back and forth between them.


Sorry for late reply.

Thankyou for testing this for me, I thought that the GtkBox in the
property editor
would be the main culprit but I'm going to try rooting out every
GtkBox in Glade's
frontend UI. It's possible that a higher-level GtkBox (perhaps even a box in the
toplevel UI) is causing the problem.

If this is true, then it would also explain the small annoying lag
that I experience
even without the Adwaita theme applied (i.e. if showing/hiding a widget, which
causes parents to have their size negotiated, hits a toplevel GtkBox,
and at that
point the box ends up queuing a resize and resetting the style of every child in
the whole UI recursively... this would definitely explain the lag).

I'll try to make a patch soon and let you know.

Thanks again for bearing with me on this.

Cheers,
           -Tristan




On Tue, Dec 27, 2011 at 7:13 AM, Micah Carrick <micah at quixotix.com> wrote:


I'm going to give it a go sometime today.


On Thu, Dec 22, 2011 at 10:53 PM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:


Ok I discussed this with Benjamin Otte on irc and made sure that other
GTK+
devs are aware of this problem.

I'm not convinced that people are taking performance issues seriously
enough
but currently I don't have time to intervene myself.

Benjamin suggested I try a workaround, it does nothing for me here but
then
again, I dont run the full blown adwaita theme so that should explain it.

The problem is that GtkBox goes and resets the css any time one of
it's children are shown or hidden, this is because the children's style's
*might* change depending on what position they are in their siblings.

Not only does this reset the style but also queues a resize, totally
trampling over the size request cache which I worked so hard to optimize
:-(

So the suggested workaround is to use a GtkGrid instead of a GtkBox,
hopefully GtkGrid will not be so evil to our editor children, I'm
attaching
the patch here which should safely apply to Glade 3.10 (or master).

Can someone with the Adwaita theme and 2 second horrible bug available
to them... try this patch for me and tell me if they see any improvement
?

Thanks for your cooperation in this.

Cheers,
? ?-Tristan

On Thu, Dec 22, 2011 at 2:36 AM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:

Ok, made the same mistake myself, somehow the last mail missed the
list...

Here it the response:

On Thu, Dec 22, 2011 at 2:36 AM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:

On Thu, Dec 22, 2011 at 1:39 AM, Micah Carrick <micah at quixotix.com>
wrote:

I should actually point out that turning off the default GNOME 3
doesn't
"fix" the issue, it just makes the lag less significant. Sounds like
what
you experienced Tristan--about half a second.


Yes, that needs to be looked into as well.

Glade does make a slight abstraction for sending events to
widget adaptors instead of sending them directly to widgets,
I don't believe that can be related (actually, this operation occurs
even for every pointer motion event and does not seem to
incur any lag).

The rest of the slowness involved might very well be related
to GTK+ geometry management, i.e. time spent in the
_gtk_container_idle_sizer().

As for the labels in the editor, their sizes should be cached
as of the first time the editor is shown, and half of the request
cycle can be triggered again if ever the width of the editor is
adjusted (should not be related).

It's possible that for some reason, either in GTK+ or possibly
Glade could work around this better... that possibly the size
request cache could be getting 'trampled' so to speak and
needlessly re-requested for the sake of a gtk_widget_show().

The process of updating the current widget class editor is
really just a matter of:
?a.) unsetting the currently selected widget in the editor
?b.) hiding the current class editor (which is packed in a vbox
? ? ? ?inside the notebook page)
?c.) showing the new class editor (since it is cached, it's already
? ? ? a child of the same vbox).
?d.) running through the property editors on that page and updating
? ? ? their current values.

So, for the most part, around 75% of the time spent on this operation
can be attributed to the css class lookup proceedure... which probably
needs work in terms of caching previous results... these lookups
should not
be done by GTK+ unless one of the deciding factors (widget name,
widget class, style change) actually change.

Perhaps that code caches things properly but maybe erronously clears
the cache for the sake of a gtk_widget_hide() or gtk_widget_show()...

Cheers,
? ? ? ? ? ? ?-Tristan




Also, I posted my last message with the wrong email, not sure if it
went
through. It's shown below:


On Wed, Dec 21, 2011 at 8:23 AM, Micah Carrick
<micah at greentackle.com>
wrote:


Ding ding ding ding!

I'm using GNOME 3 on Fedora 16 with the GNOME 3 default theme
Adwaita.?When I switch the GTK+ theme to Raleigh using Gnome Tweak
Tool the
problem is goes away. I'm not up to speed on how themes work in gtk+
3 but I
believe Raleigh does not use a theme engine.

On Wed, Dec 21, 2011 at 6:17 AM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:


Thanks !

I loaded up the file you sent and it appears that most of the time
can
be tracked
down to:
?a.) Glade handling events, which results in showing a hidden
editor
page in the
? ? ? GladeEditor widget...
?b.) When looking at the callees of glade_widget_event() one notes
that
? ? ? ?most of the time spent in there is spent in
gtk_css_provider_get_style()

Possibly the problem is around resolving things that should
probably
already
have been cached the first time around (i.e., how come we spend
time
searching
and matching css styles for the widgets in the editor if they've
been
created
at least once ?)

One thing I have never tried personally, is a GTK+ 3 installation
in /usr
and
a theme installed, is this why I am not getting such bad
performance
issues ?


Is your test case built into /usr ?? maybe that doesnt matter... do
you
get
the ugly default native GTK+ theme or are you picking up some kind
of
elaborate and beautiful theme while running Glade ?

If so, can you try running Glade in a naked environment, with no
fancy
css applied and report back if the problem persists ? (or if it's
less
bad ?)


Thanks alot for your help, I'm trying a GTK+ master build now to
see
if this is a possible regression... I havent been paying attention
to
GTK+ releases lately... maybe everyone is running something more
recent than 3.3.3.

Cheers,
? ? ? ? ?-Tristan


On Wed, Dec 21, 2011 at 9:06 AM, Micah Carrick <micah at quixotix.com>
wrote:

Hey, I'm going to attach my callgrind output in case one of y'all
know
what
you are doing better than I do. I started glade with`
--instr-atstart=no`,
added a button and a label to the window, and then turned it on
with
`callgrind_control -i on`. I then selected a different widget and
turned it
off with `callgrind_control -i off`.

I don't really know what I'm looking for the KCacheGrind just yet
and I
don't have any more time to dig around today, but all these
graphs ans
such
look pretty awesome.


On Tue, Dec 20, 2011 at 2:44 PM, Micah Carrick
<micah at quixotix.com>
wrote:


I've got 4GB RAM and a dual core AMD64... plenty fast. I have a
lag?of
1.5
- 2 seconds based on the very accurate and scientific "one
mississippi, two
mississippi..." approach. ;)

I'll see if I can tinker with valgrind sometime in the next week
or so
if
I have time.

On Tue, Dec 20, 2011 at 1:53 PM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:


On Wed, Dec 21, 2011 at 4:10 AM, Matej Nanut
<matejnanut at gmail.com>
wrote:

I've asked the same question here about a month (?) ago, and
there
was
no
definite answer,


I just tried building a few versions here, and I have pretty
much the
same lag
from GTK+ 3.0.9 to GTK+ 3.3.3, I havent tried any versions
before
3.0.9
or
after 3.3.3.

I have a very old laptop here (about 5yrs old and chugging
along,
every
second time I power her up she decides to find the operating
system...
and
grub happily shows up).

Running 64bit linux here, with this processor:
? AMD Turion(tm) 64 X2 Mobile Technology TL-58

Its dual core, each of them dishing out about 800Mhz.

Admittedly selecting a new widget is annoyingly slow,
probably around half a second or a bit more, just enough
to make you feel annoyed, definitely nowhere close to
a 2 second lag.

Currently I'm really busy with other things and can't be
bothered... so I'm looking to you guys to profile it and find
out where is the bottle neck, where are we spending the
majority of this time ?

In size requests ? is it a silly Glade bug ?

I recommend valgrind with the cachegrind tool, output
is quite pretty when viewed with kcachegrind.

And it doesnt require hacking your kernel like other modern
profilers do...

Cheers,
? ? ? ? ? ? ?-Tristan


apart from it probably being GTK's and not Glade's fault.
I just opted to actually coding my interfaces until this gets
corrected.

Sorry I couldn't be of much help,
Matej

On 20 December 2011 20:03, Micah Carrick <micah at quixotix.com>
wrote:


I've seen a few other people mentioning this, but, I can't
find
any
bugs
or information. What I'm seeing is that when you select from
one
widget to
another (either in the editor or the inspector) the UI
blocks for
about 2
full seconds. This only happens when selecting a widget of a
different
type
than the one currently selected (eg. selecting a GtkButton
and
then
another
GtkButton is fast, but then selecting a GtkEntry is slow).

Any insights?



_______________________________________________
Glade-users maillist ?- ?Glade-users at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users




_______________________________________________
Glade-users maillist ?- ?Glade-users at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-users











--
? ? Green Tackle - Environmentally Friendly Fishing Tackle
? ? www.GreenTackle.com

???? Email: micah at greentackle.com
???? Phone: 971.270.2206
???? Toll Free: 877.580.9165
???? Fax: 503.946.3106
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]