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

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