Am Fri, 29 Sep 2006 12:54:11 -0500 schrieb Federico Mena Quintero: > On Thu, 2006-09-28 at 20:13 +0200, Adalbert Dawid wrote: > >> 1. GtkTreeView's repaints are slow. This gets especially obvious, when you >> perform one of the actions below: >> * Resize a column (i.e. change its width). You will notice that the >> header is badly lagging behind the mouse pointer, which gets worse as >> one enlarges the viewport. >> * Drag an icon from the Desktop over a big nautilus window with many >> files and directories in the list view mode. When you keep moving the >> icon over nautilus, the CPU goes up to 100% and the icon leaves an ugly >> white trail. > > What theme engine are you running?
I have been a Gnome user for some years now (IIRC I switched to Gnome when 2.4 was released), so I had the chance to run many engines. Some of them are slower and some are faster, but none of them feels *really* fast. Currently I'm running (mainly) the non-cairo version of Clearlooks, which I regard as one of the fastest engines available. > > Are you running a compositing manager? If so, which one, and which > graphics driver do you have? I have a Debian Etch partition (productive system) without a compositing manager and an Ubuntu Edgy partition (for playing around) with Xgl. My graphics card is a GeForce 5700 LE (128 MB video mem) driven by the proprietary nvidia drivers. In addition, I have a HP Compaq nx9005 notebook with a low-end ATI graphics card, which has the advantage that it is very well supported by the free radeon driver. Even AIGLX runs on it and is (nearly) usable. Again: on some hardware GTK is a bit faster, on the other it is a bit slower (I have the feeling that the free nv driver is even faster than the proprietary driver from nvidia), but the slowness of GtkTreeView and of window-resizing is omnipresent, AFAICT. > > On my non-composited, Xorg Radeon setup (IBM Thinkpad T41p), I don't get > lagging when I resize the columns in Nautilus's list view. I get only > minimal trailing (1 or 2 "positions") when I do drag and drop over it. > I'm using Novell's "Gilouche" theme, which is essentially pre-Cairo > Clearlooks. What resolution does your Thinkpad's screen have? My observation is that the lagging gets worse when the list contains many entries (30 should be enough) and the visible area is high (i.e. large in vertical direction). This tends to be the case more often on high-res screens (say, 1280x1024), e.g. when you maximize a nautilus window. > > Can you run a global profiler like sysprof to identify the culprit? > Unfortunately I am not really a C programmer (I do have basic knowledge, but I mainly code in Java) and I did not run sysprof or other C-related profiling tools before. But I think I could install sysprof and give it a try in the next days. > Apart from that, GtkTreeView *does* have problems. GtkCellRendererText > is written in a way that each repaint cycle causes it to re-layout the > same string two or three times. On a treeview with a lot of text, this > is the hotspot in the profile: > http://primates.ximian.com/~federico/news-2005-10.html#gtkfilechooser-profile-4 > > That doesn't look terribly hard to fix; it's just that no one has done > it yet :) I will have a look on that, but can't promise anything... > > We need a set of benchmarks for GtkTreeView. I'd start with comparing > various operations (layout, column resizing, repaint, etc.) between a > treeview with no-op cell renderers, and busy text renderers. > >> 2. Resizing of GTK windows is slow. This effect, too, is getting worse >> the bigger the resized window is. It is very interesting to see, that a >> really small (say, 200*200 pixels) window can be resized pretty smoothly, >> even if it is full of widgets that need to be layouted. Another >> observation is, that even an empty GTK window (i.e. one with a plain grey >> backgroud and no widgets) repaints really slowly when you resize it on a >> screen with high resolution and drag it large. > > Again, which theme engine, and which compositing manager? Does your > engine paint gradients or other exotic stuff on the otherwise plain > window background? > > With my setup, an empty window resizes quite quicly. It is a bit slower > when the window gets close to full-screen (1400x1050), but I can't get > it to lag or anything. Yes, you are right, an empty window is not so problematic. My description was faulty, sorry for the confusion. What I really meant was exactly what you are describing below: a single big button in a window. Then the resizing gets really slow, even if you choose a very simple engine that does not paint any gradients. > It's interesting to note that if I add a single button to the window, > then it gets noticeably slower (but it doesn't lag, either). Then, > Sysprof says that 69% of the time is spent in libfb/libxaa in the X > server, not GTK+ itself. Then, maybe X is the real bottleneck. Or GTK utilizes X drawing functions in some inefficient way... If the GTK engine has to paint a plain, single coloured button, then this operation should not take any longer than drawing a plain rectangle on the root X window (of course apart from the text on the button etc.), should it? Otherwise there must be something that GTK is doing wrong... > > Federico Adalbert _______________________________________________ Performance-list mailing list Performance-list@gnome.org http://mail.gnome.org/mailman/listinfo/performance-list
