Re: [linux-audio-dev] GTK performance?

On Thu, 2005-04-28 at 15:30 +0200, Tim Orford wrote:
> .
>
> Firstly, you will get a better answer on the gtk.apps.devl list where
> gtk developers hang out.
>
Makes sense ...

> What version of gtk are you using? There have been a huge number of
> enhancements made over the the various 2.2/2.4/2.6 releases, so much
> so that it can be difficult to keep track of them.
>
$ locate libgtk
  /usr/lib/libgtk-x11-2.0.so.0.400.9
  /usr/share/doc/libgtk+2.0_0-devel-2.4.9

> The pixmap engine is known to have performance problems. Have you
> tried using something like Smooth? I see you tried the Eazel engine
> but i'm not personally familiar with that.
>
Eazel used to be default in Mandrake (with som Mdk-blue colours)
Galaxy is their default now. OK-ish, but perhaps lacking elegance
Mist is the performance winner. Very black & white 1985-ish for my
application though.
Smooth performs like galaxy but supersizes everything (Now where did
that exit button go ...)

> How are you measuring cpu usage? This is something i would like to know
> more about. The figures are only averages of course. As long as the
> usage is of short duration, it should leave plenty of cycles for audio
> processing, no? I personally find the output of xosview to be very useful,
> as having a fast graphical indicator, can show more meaningful info than
> a number.

For monitoring cpu-usage around 99% I use a little flame in a 64x64
window running *very* nice. When the flame starts to get choppy, I count
the seconds beween updates. Spikes in "normal" cpu-usage creates cosy
visible patterns.

In a similar way I can measure the performance of a gtk-theme. If the
widgets updates in a second when idle they will need 10 seconds under
90% load.

I have top running as well. Here the interesting part is the difference
between (100% - 'idle time') and the sum of running processes. In the
case at hand there is 0% idle but only 65% used, indicating that some
heavy cache trashing might be going on. The X server uses almost
everything. Mmm, wait ... There is also 9% system time, probably the
pipe into the X server.

>
> And Gtk does do much of its painting in low priority Idle Functions.
> If your machine is busy, they will be queued and thinned out.
> (I cant remember offhand precisely when this is and is not true.)
>
I have noticed that switching between two sounds with similar settings
(the one being a variant of the other) updates considerably more quickly
than if each and every parameter is different. So somebody must have
been doing some good thinking there.

> >
> > Using Page Up/Down to manipulate a scale, I get 100% cpu at times when
> > the the scale is at max (respectively min), hence no redrawing should
> > take place (because oldValue == newValue.)
>
> Yes its frustrating when all toolkits repaint unnceccesarily. But in
> this case, i would have thought that it was unimportant, as the worst
> case is the one to focus on? If your system can deal with repainting
> the GtkScale(?), then a few extra occasionally wont change anything, surely?
>

Yes the min/max is not important. It is the inbetweens that count. And
switching sounds when 200+ widgets has to be updated in one go.

Anyways, about the underperforming pixmap theme, I think I am tracking
down the problem. My scales are connected to a numeric spinbox as well,
and *that* spinbox is having some very fancy scaled image background.

This screenshot is with the g5-ish pixmap theme. You can see that text
entries & friends have a shining background.

  http://hem.passagen.se/ja_linux/Mx44.jpg

Comparing with the performance of gnome-alsa-mixer (sans spinbox) is
indicative of this to be the case.

Disabling the scaled bgpixmap behind the spinbox might help?

> But gtk is pretty flexible. Have you considered copying gtkscale.c and
> making your own widget class?
>
I am telling meself not to consider it and stay focused on what I wanted
to from the beginning :))

-- 
   (
    )
  c[]  //  Jens M Andreasen