Re: Scrolling performance

[Michael Ekstrand <mekstran scl ameslab gov>]

On Jul 6, 2006, at 1:28 PM, Roo wrote:
> On Thu, 06 Jul 2006 08:21:56 -0500, Michael Ekstrand wrote:
> > Part of the problem/reason: for some reason, it seems to work (or at
> > least give acceptable results) for many of us.
>
> No doubt, when you throw enough hardware at problems it does tend to 
> hide
> them.

Did you read the list of hardware I mentioned not having problems on?  
One was a dual-600MHz PIII (running FreeBSD, FWIW).  Not exactly a 
powerhouse of a piece of hardware.  It may have been a little slow, but 
not problematically.  I had no issues running ROX Filer on it.  I do 
remember that I was using a Motif build of GVim on that machine, but 
don't remember my reasons.  The 1.4GHz laptop (with an Intel graphics 
chipset and no DRI) runs quite acceptably though, and is running GNOME 
2.14.

> > So basically: there are more variables than just GTK.
>
> Ok, so presumably there's a way to take gtk2-2.8.19-2.src.rpm (the
> currently installed GTK2 on my FC5 system) and recompile it (or is 
> there
> an env var?) telling it not to use Cairo so I can see if there's a
> difference and hence narrow things down.

Looking at configure.in in the GTK2.8 sources, it appears that there is 
no way to disable cairo.

> I could also use a recommendation
> for a benchmark app to generate some hard numbers under the different
> setups.

Check out gtkperf.  I haven't used it, but it claims to to benchmark 
GTK.

> I'm seeing these issues, and I'm fed up of them not being fixed. I'd 
> like
> to know what tools the GTK developers use for measuring performance
> changes, and how I can cut out Cairo in order to get a grip on exactly
> what is going on.

Are you using the GTK default theme?  I'd try cutting any non-default 
themes out first.  And it looks like Cairo can't be removed, for better 
or worse.

> > Further, GTK seems to value correctness and straightforwardness over
> > speed.  Not necessarily bad - computer time is cheaper than programmer
> > time.  And it's had some great results.  GTK widgets are highly 
> > capable.
> > But I can see it getting slow.
>
> I know you are trying to cover the bases here, but that just doesn't 
> cut
> it as an excuse. GTK2 has been slow from the beginning, and it's 
> getting
> slower. Other toolkits, like Qt (which I don't like I must stress), 
> manage
> to be correct and avoid the major performance problems that have 
> plagued
> GTK for years now.

Depends on your perspective.  As an application developer, I find GTK's 
performance adequate (except maybe on Mac, but I haven't done much 
testing in that department), and I find its API so clean and easy to 
use, and so saving of my development time, that I don't mind whatever 
performance hit there is.  Same argument as is made for developing in 
Python vs. C.

That said, we should attempt to improve GTK performance as much as is 
feasible.

> > OK, so this has turned into a bit of a stream-of-conciousness message.
> > But I hope it helps some...  and it most definitely is not intended 
> > as a
> > flame, so please don't take it as one.
>
> I didn't take it as one... but I'd like some advice from anyone on
> narrowing down the problem so it can be fixed rather than just ignored
> again.

Profile.  What happens if you build Cairo, GTK and GTKperf or gtk-demo 
or something with profiling enabled, and look at the profiling data?  
Where are GTK and Cairo spending their time?  Is it spent in Cairo 
drawing calls, or in GTK double-buffering (from what Clemens has said 
he's accomplishing, it seems the latter)?  Then start looking for 
obviously inefficent ways things are happening in the area surrounding 
the hot spots.

From the discussion surrounding the issues Clemens is working on, it 
seems like there are some things that GTK does do inefficiently.  And 
it seems that some optimization of the double buffering code is 
improving the situation greatly.

- Michael