Discussion:
GTK performance?
(too old to reply)
Jens M Andreasen
2005-04-28 09:45:57 UTC
Permalink
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
Steve Harris
2005-04-28 10:14:08 UTC
Permalink
Post by Jens M Andreasen
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
Jens M Andreasen
2005-04-28 10:46:50 UTC
Permalink
Post by Steve Harris
Post by Jens M Andreasen
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).
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.
Post by Steve Harris
- Steve
--
(
)
c[] // Jens M Andreasen
Jens M Andreasen
2005-04-28 12:18:45 UTC
Permalink
Post by Jens M Andreasen
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
Billy Biggs
2005-04-28 13:01:05 UTC
Permalink
Post by Jens M Andreasen
Post by Jens M Andreasen
What is even "funnier" is that mouse behaviour seems to take a
different route with next to no overhead.
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.
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
Steve Harris
2005-04-28 13:08:23 UTC
Permalink
Post by Jens M Andreasen
Post by Steve Harris
Post by Jens M Andreasen
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).
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.

- Steve
Jens M Andreasen
2005-04-28 13:48:21 UTC
Permalink
Post by Steve Harris
Post by Jens M Andreasen
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.
double x;
...

!(x > 1.3) && !(x < 1.3) ? ... : ... ;
Post by Steve Harris
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
d***@pawfal.org
2005-04-28 12:15:57 UTC
Permalink
Post by 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?

cheers,

dave
Jens M Andreasen
2005-04-28 12:29:09 UTC
Permalink
Post by d***@pawfal.org
Post by 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?
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
Tim Orford
2005-04-28 13:30:29 UTC
Permalink
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
Jens M Andreasen
2005-04-29 05:30:31 UTC
Permalink
Post by Tim Orford
.
Firstly, you will get a better answer on the gtk.apps.devl list where
gtk developers hang out.
Makes sense ...
Post by Tim Orford
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
Post by Tim Orford
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 ...)
Post by Tim Orford
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.
Post by Tim Orford
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.
Post by Tim Orford
Post by Jens M Andreasen
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.

Loading Image...

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?
Post by Tim Orford
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
Tim Orford
2005-04-29 13:17:14 UTC
Permalink
Post by Jens M Andreasen
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
Post by Jens M Andreasen
http://hem.passagen.se/ja_linux/Mx44.jpg
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
Jens M Andreasen
2005-04-29 13:55:31 UTC
Permalink
Post by Tim Orford
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!
Post by Tim Orford
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)
Post by Tim Orford
cheers
--
(
)
c[] // Jens M Andreasen
Jens M Andreasen
2005-04-30 02:03:06 UTC
Permalink
Post by Tim Orford
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!
Post by Tim Orford
cheers
--
(
)
c[] // Jens M Andreasen
Steve Harris
2005-04-29 14:43:19 UTC
Permalink
Post by Jens M Andreasen
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
Paul Coccoli
2005-04-29 15:09:13 UTC
Permalink
Post by Steve Harris
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...
Lee Revell
2005-04-28 17:14:30 UTC
Permalink
Post by Jens M Andreasen
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
Juhana Sadeharju
2005-05-03 15:42:29 UTC
Permalink
Post by Jens M Andreasen
Is it gtk then? Or the pixmap engine?
I don't use pixmap decorations in my application, but
only one pixmap of size 800x600 was too slow. I used
the preferred pixmap functions of GTK2. The expose of
the whole 800x600 pixmap took 120 ms (8 fps). That was
impractical.

Then I switched to gtkglext which in my system apparently
uses Mesa with software renderer. (How to verify it?)
Now the system is fast. One app renders 3D objects and another
app draws 2D objects (Loading Image...).

I would like to know if gtkglext in my system uses Mesa and
if Mesa uses software renderer. How that can be tested?

What I would like to have would be vertex and fragment
shaders for audio widgets. E.g., a 2D or 3D knob would
rotate with vertex shaders. E.g., a level meter a la
SoundForge would have a fragment shader dimming the top of
the black-green-yellow-red texture map based on the meter
value.

Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Steve Harris
2005-05-03 15:58:39 UTC
Permalink
Post by Juhana Sadeharju
Post by Jens M Andreasen
Is it gtk then? Or the pixmap engine?
I don't use pixmap decorations in my application, but
only one pixmap of size 800x600 was too slow. I used
the preferred pixmap functions of GTK2. The expose of
the whole 800x600 pixmap took 120 ms (8 fps). That was
impractical.
Then I switched to gtkglext which in my system apparently
uses Mesa with software renderer. (How to verify it?)
Now the system is fast. One app renders 3D objects and another
app draws 2D objects (http://www.funet.fi/~kouhia/enved7.png).
I would like to know if gtkglext in my system uses Mesa and
if Mesa uses software renderer. How that can be tested?
I think Mesa is the software renderer. If you run glxinfo it will tell you
the vendor of the driver, which will be Mesa if its software, or thename of
the graphics card manufacturer or Xorg driver etc. if its hardware.
Post by Juhana Sadeharju
What I would like to have would be vertex and fragment
shaders for audio widgets. E.g., a 2D or 3D knob would
rotate with vertex shaders. E.g., a level meter a la
SoundForge would have a fragment shader dimming the top of
the black-green-yellow-red texture map based on the meter
value.
Beware: not all current cards have shader support, though basic GL is
widespread. Also linux support for shaders is limited to the closed source
drivers I think, which many people will object to on philoshical grounds.

- Steve

Continue reading on narkive:
Loading...