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

On Wed, Dec 28, 2011 at 12:59 AM, Micah Carrick <[email protected]> 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 <[email protected]> wrote:
>>
>> I'm going to give it a go sometime today.
>>
>>
>> On Thu, Dec 22, 2011 at 10:53 PM, Tristan Van Berkom
>> <[email protected]> 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
>>> <[email protected]> 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
>>> > <[email protected]> wrote:
>>> >> On Thu, Dec 22, 2011 at 1:39 AM, Micah Carrick <[email protected]>
>>> >> 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
>>> >>> <[email protected]>
>>> >>> 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
>>> >>>> <[email protected]> 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 <[email protected]>
>>> >>>>> 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
>>> >>>>> > <[email protected]>
>>> >>>>> > 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
>>> >>>>> >> <[email protected]> wrote:
>>> >>>>> >>>
>>> >>>>> >>> On Wed, Dec 21, 2011 at 4:10 AM, Matej Nanut
>>> >>>>> >>> <[email protected]>
>>> >>>>> >>> 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 <[email protected]>
>>> >>>>> >>> > 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  -  [email protected]
>>> >>>>> >>> >> http://lists.ximian.com/mailman/listinfo/glade-users
>>> >>>>> >>> >>
>>> >>>>> >>> >
>>> >>>>> >>> >
>>> >>>>> >>> > _______________________________________________
>>> >>>>> >>> > Glade-users maillist  -  [email protected]
>>> >>>>> >>> > http://lists.ximian.com/mailman/listinfo/glade-users
>>> >>>>> >>> >
>>> >>>>> >>>
>>> >>>>> >>>
>>> >>>>> >
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>>     Green Tackle - Environmentally Friendly Fishing Tackle
>>> >>>>     www.GreenTackle.com
>>> >>>>
>>> >>>>      Email: [email protected]
>>> >>>>      Phone: 971.270.2206
>>> >>>>      Toll Free: 877.580.9165
>>> >>>>      Fax: 503.946.3106
>>> >>>>
>>> >>>>
>>> >>>
>>
>>
>
_______________________________________________
Glade-users maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-users