28 Apr
2005
28 Apr
'05
7:45 a.m.
Hi all!
The other day I dressed up my application with a fancy g5-ish pixmap
theme. Looks good and expensive :)
As it turned out, it really was expensive (counting cpu-clocks.)
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.)
I then measured X using an Xterm, holding down a key to get the key to
repeat. Really, no sweat! Just a srolling window with gibberish. So X is
as far as I can see not at fault.
Is it gtk then? Or the pixmap engine?
I thought I'd go and listen to the horses mouth and fired up The
Gimp ...
Uhmm! Those guys really do not wish to use the pixmap engine and
replaces the scales with what comes out of the eazel-engine (Crux &
friends.)
With key Page Up/Down and the eazel-engine, I still get 20% CPU.
This is kind of expensive for essentially doing nothing.
My conclusion is that there is something deeply wrong inside gtk,
regarding handling of signals and/or redraw. This is bad news for RT
audio people using gtk.
In comparison, letting FlightGear redraw the polygons of the Himalaya
ranges looks kind of cheap :-/
Comments?
Reference machine: 1.1Ghz Celery. Gtk-2.0
--
(
)
c[] // Jens M Andreasen
28 Apr
28 Apr
8:14 a.m.
On Thu, Apr 28, 2005 at 11:45:57 +0200, Jens M Andreasen wrote:
Hi all!
The other day I dressed up my application with a fancy g5-ish pixmap
theme. Looks good and expensive :)
As it turned out, it really was expensive (counting cpu-clocks.)
Unless you have an ultra-bleeding edge X setup a lot of the work of the
pixmap drawing is done by the CPU, thats quite a lot of maths. There is
some new tech which uses OpenGL to do the X drawing, which moves a lot of
the load off to the graphics card, but its not really available yet.
http://freedesktop.org/wiki/Software_2fXgl
This /really/ helps, for e.g. I have a beta version of meterbridge that
can use OpenGL or SDL (X) pixmaps, on my thinkpad (which has a comparitivly
hardcore graphics chip, but its only a laptop) I can fill the screen with
32 scaled VU meters at about 3% CPU load, with SDL it maxes out the CPU
when I have about half that number of unscaled meters (the SDL code doesnt
do scaling, its too expensive).
- Steve
8:46 a.m.
On Thu, 2005-04-28 at 11:14 +0100, Steve Harris wrote:
On Thu, Apr 28, 2005 at 11:45:57 +0200, Jens M
Andreasen wrote:
Still leaves me wondering how on earth gtk can use the equivalence of a
200 Mhz pentium to figure out that nothing happened?
So a faster redraw is of course always welcome, but redrawing (or
whatever is going on) when old == new is really not on my todo list.
What is even "funnier" is that mouse behaviour seems to take a different
route with next to no overhead.
Hi all!
The other day I dressed up my application with a fancy g5-ish pixmap
theme. Looks good and expensive :)
As it turned out, it really was expensive (counting cpu-clocks.)
Unless you have an ultra-bleeding edge X setup a lot of the work of the
pixmap drawing is done by the CPU, thats quite a lot of maths. There is
some new tech which uses OpenGL to do the X drawing, which moves a lot of
the load off to the graphics card, but its not really available yet.
http://freedesktop.org/wiki/Software_2fXgl
This /really/ helps, for e.g. I have a beta version of meterbridge that
can use OpenGL or SDL (X) pixmaps, on my thinkpad (which has a comparitivly
hardcore graphics chip, but its only a laptop) I can fill the screen with
32 scaled VU meters at about 3% CPU load, with SDL it maxes out the CPU
when I have about half that number of unscaled meters (the SDL code doesnt
do scaling, its too expensive).
- Steve
--
(
)
c[] // Jens M Andreasen
10:15 a.m.
My conclusion is that there is something deeply wrong
inside gtk,
regarding handling of signals and/or redraw. This is bad news for RT
audio people using gtk.
granted, this is important for general purpose issues, but isn't this all
irrelevant if you are using a realtime audio thread?
cheers,
dave
10:18 a.m.
On Thu, 2005-04-28 at 12:46 +0200, Jens M Andreasen wrote:
What is even "funnier" is that mouse
behaviour seems to take a different
route with next to no overhead.
Correction:
Mouse-wheeling shows a similar (over-the-top cycle consuming) behaviour
as key input. It appears to be the entry of the event as such that
spawns the effect.
--
(
)
c[] // Jens M Andreasen
10:29 a.m.
On Thu, 2005-04-28 at 05:15 -0700, dave(a)pawfal.org wrote:
No, because I manipulate the sound in realtime and I have no visual
feedback of what is going on when the machine is actually doing audio
(as opposed to just sitting there, looking pretty.)
--
(
)
c[] // Jens M Andreasen
My conclusion
is that there is something deeply wrong inside gtk,
regarding handling of signals and/or redraw. This is bad news for RT
audio people using gtk.
granted, this is important for general purpose issues, but isn't this all
irrelevant if you are using a realtime audio thread? 
11:01 a.m.
Jens M Andreasen (jens.andreasen(a)chello.se):
On Thu, 2005-04-28 at 12:46 +0200, Jens M Andreasen
wrote:
Regardless of what the toolkit is, avoiding redrawing areas which have
not changed is often an important performance improvement. I think you
should file a bug about your specific case on bugzilla.gnome.org.
The pixmap theme engine itself is of course quite slow due to how it
works. I would not recommend ever using any theme based on this engine.
-Billy
What is even "funnier" is that mouse
behaviour seems to take a
different route with next to no overhead.
Correction:
Mouse-wheeling shows a similar (over-the-top cycle consuming)
behaviour as key input. It appears to be the entry of the event as
such that spawns the effect.
11:08 a.m.
On Thu, Apr 28, 2005 at 12:46:50 +0200, Jens M Andreasen wrote:
On Thu, 2005-04-28 at 11:14 +0100, Steve Harris
wrote:
Well, determinging if two floating point numbers are the same is a non
trivial operation. There can be multiple encodings of, say, 1.3 depending
on how you got there.
I suspect they take a conservative view and always redraw if thye cant tell
thier the same.
- Steve
On Thu, Apr 28, 2005 at 11:45:57 +0200, Jens M
Andreasen wrote:
Still leaves me wondering how on earth gtk can use the equivalence of a
200 Mhz pentium to figure out that nothing happened? Hi all!
The other day I dressed up my application with a fancy g5-ish pixmap
theme. Looks good and expensive :)
As it turned out, it really was expensive (counting cpu-clocks.)
Unless you have an ultra-bleeding edge X setup a lot of the work of the
pixmap drawing is done by the CPU, thats quite a lot of maths. There is
some new tech which uses OpenGL to do the X drawing, which moves a lot of
the load off to the graphics card, but its not really available yet.
http://freedesktop.org/wiki/Software_2fXgl
This /really/ helps, for e.g. I have a beta version of meterbridge that
can use OpenGL or SDL (X) pixmaps, on my thinkpad (which has a comparitivly
hardcore graphics chip, but its only a laptop) I can fill the screen with
32 scaled VU meters at about 3% CPU load, with SDL it maxes out the CPU
when I have about half that number of unscaled meters (the SDL code doesnt
do scaling, its too expensive). 
11:32 a.m.
On Thu, Apr 28, 2005 at 11:45:57AM +0200, Jens M Andreasen wrote:
ve The other day I dressed up my application with a
fancy g5-ish pixmap
theme. Looks good and expensive :)
hi
I'd like to know more about this, but dont have time to investigate
fully, so just some quick comments...
Firstly, you will get a better answer on the gtk.apps.devl list where
gtk developers hang out.
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.
Is it gtk then? Or the pixmap engine?
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.
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.
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.)
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?
But gtk is pretty flexible. Have you considered copying gtkscale.c and
making your own widget class?
Anyway, Gtk is slowly moving to using Opengl on the backend, so
the future isnt looking too bad in this regard. Patience may be more
rewarding in this case than spending time on a proprietory workaround.
cheers
--
Tim Orford
11:48 a.m.
On Thu, 2005-04-28 at 14:08 +0100, Steve Harris wrote:
double x;
...
!(x > 1.3) && !(x < 1.3) ? ... : ... ;
Still leaves
me wondering how on earth gtk can use the equivalence of a
200 Mhz pentium to figure out that nothing happened?
Well, determinging if two floating point numbers are the same is a non
trivial operation. There can be multiple encodings of, say, 1.3 depending
on how you got there.
I suspect they take a conservative view and always redraw if thye cant tell
thier the same.
Still, the pixmap is fairly small, 20 × 20 perhaps. It shouldn't take
all day :)
--
(
)
c[] // Jens M Andreasen
3:14 p.m.
On Thu, 2005-04-28 at 11:45 +0200, Jens M Andreasen wrote:
Hi all!
The other day I dressed up my application with a fancy g5-ish pixmap
theme. Looks good and expensive :)
As it turned out, it really was expensive (counting cpu-clocks.)
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.)
Run it under gdb and background the process while it's in the CPU
burning loop, then look at the backtrace.
Lee
29 Apr
29 Apr
3:30 a.m.
On Thu, 2005-04-28 at 15:30 +0200, Tim Orford wrote:
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?
.
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?
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
11:18 a.m.
On Fri, Apr 29, 2005 at 07:30:31AM +0200, Jens M Andreasen wrote:
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.
Cool
Wow, lots of gtkscales!:-)
Btw, its quite fast and snappy here (no fancy bg pixel maps).
I dont know if you realise that command line args are not
reaching gtk_init(), so eg "--display" args are ignored.
Also, personally i would add a gtkscrollwin so the minimum
window size can be smaller.
I look forward to playing with mx44 properly over the w/e...
cheers
--
Tim Orford
11:55 a.m.
On Fri, 2005-04-29 at 15:17 +0200, Tim Orford wrote:
I dont know if you realise that command line args are
not
reaching gtk_init(), so eg "--display" args are ignored.
No, it used to work? .. Looking in to it!
Also, personally i would add a gtkscrollwin so the
minimum
window size can be smaller.
I look forward to playing with mx44 properly over the w/e...
There is a last minute change in the waweshaper uploaded now. Ever so
slightly brighter and works cleaner together with FM-synthesis. (Or it
is me that is geting the "Golden Ear" syndrome)
cheers
--
(
)
c[] // Jens M Andreasen
12:43 p.m.
On Fri, Apr 29, 2005 at 07:30:31AM +0200, Jens M Andreasen wrote:
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.
Top is pretty useless for measuring loads that aren't constant. It seems
to sample CPU loads at instants in time, which is why top is always high
on the list. I tend to use gkrellm.
- Steve
1:09 p.m.
On 4/29/05, Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
Top is pretty useless for measuring loads that
aren't constant. It seems
to sample CPU loads at instants in time, which is why top is always high
on the list. I tend to use gkrellm.
Andrew Morton's zc package
(http://www.zipworld.com.au/~akpm/linux/#zc) contains a tool called
cyclesoak that I like to use for measuring CPU usage. It's a simple
command line app. I like that because I can easily store its output
for comparing different runs. Useful for profiling sometimes.
I moded it to spit out average usage over a run upon exit. Hopefully
my mod doesn't invalidate the whole thing...
30 Apr
30 Apr
12:03 a.m.
On Fri, 2005-04-29 at 15:17 +0200, Tim Orford wrote:
I dont know if you realise that command line args are
not
reaching gtk_init(), so eg "--display" args are ignored.
A dangerous bug leading to corruption of command line and internal
lockup.
Fixed!
cheers
--
(
)
c[] // Jens M Andreasen
6959
days inactive
6960
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
7 participants
participants (7)
-
Billy Biggs -
dave＠pawfal.org -
Jens M Andreasen -
Lee Revell -
Paul Coccoli -
Steve Harris -
Tim Orford