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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
