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
