GNOME Bugzilla – Bug 113040
Do predictive exposes for override redirect windows
Last modified: 2011-02-04 16:17:18 UTC
I use a number of different Linux distros and FreeBSD. They _all_ have the same problem on this PIII 700 Mhz (and on my dual-Celeron 533). If I use Abiword 1.9x, Galeon 1.3.x and any other "heavy" GTK+ 2.x application (and that includes even Nautilus) the context menus for these apps are just very slow. What I mean is this: Use a 2-year old PC, get Galeon 1.3.x, load a web page, right click anywhere on that page. The first thing you will see is the actual menu window drawing and AFTER a short while, you will see this menu window getting populated by its menu options. It is just slow. Sure, it only takes a second or something, but compared to ALL other OSes and toolkits I use (and that even includes GTK+ 1.x), this behavior really makes me feel that GTK+ context menus are crawilingly slow. As I noted above, other complex GTK+ 2.x apps also exhibit the problem, depending in the complexity of the drawed background. When right clicking in the Gnome desktop, even Nautilus' context menu is not as fast as it should have been. Sure, it ain't as slow as Galeon or AbiWord, but it is still not as responsive as it should have been. It happens on all my distros and FreeBSD, and please note I have all the needed Xfree extensions and 2D acceleration ON. Is there any profiling and optimizations scheduled for GTK+ 2.4.x? Please... :)
I'm not a GTK+ coder, but until last month I had a 500MHz Pentium, and never saw any slowness in context menus (Geforce2 MX graphics card). Does this delay really occur in all applications? Try gedit -- the complexity of the background shouldn't affect drawing speed for the menu.
Hmm, I don't see this with most GTK+ apps. I don't use Galeon so maybe it is a Galeon problem. In nautilus, after it's been sitting there for a few hours unused, the right click root menu popup is instaneous for me on a 1.13ghz PIII ... a little faster than your machine, but not a whole lot. There are some Pango performance improvements upstream, but your describing something so drastic that whether we can lay out 200,000 characters a second or 500,000 a second isn't going to make a bit of difference.
Galeon 2 context menu pops up instantly for me.
>Does this delay really occur in all applications? Try gedit On Gedit is much faster. But Nautilus, Galeon, Epiphany AND Abiword 1.9.x and any other "complex" app exhibit the problem of the slow context menu rendering/display. >the right click root menu popup is instaneous for me on a 1.13ghz PIII Actually this is quite faster than a PIII 700 or even more, my dual celeron 533 (256 MB RAM). Could you please load a page with Galeon 1.3.x, Epiphany or Abiword 1.3.x or any other "real" app (as opposed to a utility) on a PII or Celeron machine and then check out the speed of its context menu? Here, it is considerably slow, I can see the actual creation of the window and then the population of the menu options. It overall doesn't take more than 1 or 1.3 seconds, but it is visibly slower than any other toolkit or OS I use in these machines. Thanks. :)
My PII-450MHz (dual) with RH9 doesn't have this problem. The only thing I can suggest is memory exhaustion is causing it. What does vmstat show?
FWIW, I've seen this problem on machines with NVidia drivers. Definitely not a gtk+ issue there.
I'm using Nvidia drivers on the PII-450 above (it's the only reason it feels even remotely usable) without this issue. Note though, that some versions of the Nvidia drivers appear to leak memory quite badly which results in major slowdown after a week or two of Xwindows uptime. Ctrl-Alt-Backspace time.
I use a Voodoo5 and a Matrox G400 for these machines. My nvidia card is on another much faster machine here (AthlonXP 1600+) so the Linux distros in that faster machine don't exhibit the problem (and regarding nvidia, I only use the plain "nv" driver, as the nvidia drivers crash on that machine because of the VIA chipset (nvidia knows of this)). So, I really don't think it is a driver problem... Is there something I can do to "measure" GTK+ 2.x performance and give you some hard numbers, in regards to galeon or abiword or other more advanced apps? I am convinced that this is simply a perfomance problem that I see because I use many different OSes and toolkits. Other people, might see the same lag in context menu performance on these apps and take it for granted, if they don't use much other OSes/toolkits... It is one of these things that is hard to prove unless you are sitting next to me. :D
Actually, on rare occasions, I think I have seen what you are talking about - I'll pop up a menu and it will stick for a fraction of a second before redrawing. Probably what is happening is that between popping up the menu and handling the expose something else gets scheduled and takes a while before returning control to the app. I really have no idea if this is your problem or not, if it is, there is one thing that we can do to fix help it. Currently, the sequence for drawing any window is: A) Pop up window B) Wait for window to get mapped C) Handle expose events generated for mapping But actually, menus are a special sort of window - "override redirect", and step B) isn't necessary. Normally step B) is there to wait for the window manager to map the window, but the window manager isn't involved for menus. So, by special-casing override redirect windows, we should be able to get rid of the context switch to the X server and back between popping up the window and drawing it, which will make it less likely that some other process gets scheduled in between. It's probably about a half day of work to implement. Then again, this might not be your problem at all...
Please implement it for GTK+ 2.4 and when Gnome 2.4 comes out, I will retry it and let you know if it's fixed. I guess, that's the only way to find out if this is the case indeed. Except if you are vising the Bay Area, in which case you can always come by and have a look at it first hand. :-)
Try a right click on the any window title (running metacity). This will show a popup menu with no icons. Tell if it feels slow. Perhaps the delay is because of loading icons or such.
>Try a right click on the any window title (running metacity). This comes up immediately without a lag indeed. However, doing a right-click on Epiphany also comes up immediately and that menu does have icons, so I don't think the icons are the culprit here. You see, if you load Preferences/File_Management it will have the lag and the flickering, even if there are no icons in that window.
Created attachment 26639 [details] [review] Patch to do this for both override redirect and child windows.
Patch looks good, with two comments: - It's possible to have override-redirect windows that aren't GDK_WINDOW_TEMP. To keep things clean, I think I'd put a guint override_redirect : 1 at the end of GdkWindowImplX11 - (there is space there.) This also lets us ix a problem in gdk_window_reparent() where if we reparent a window to a child and back we lose the fact that it is override redirect but it stays override redirect. - Is adding a gdk_window_is_viewable() check a worthwhile optimization? We generally map windows leaf-nodes first.
I noticed a problem with tooltips not redrawing correctly with this patch. When a new tooltip is shown, this happens: - The tooltip window is unmapped - The label is changed - gtk_window_show() is called, which resizes the window to its new size and calls size_allocate. It doesn't bump the configure_event_count counter. - Since tooltip windows are toplevels, GDK waits for the ConfigureNotify to arrive before updating the width/height - The tooltip window is mapped and invalidated, but since GDK don't know the new size, only the old part of the window is invalidated. - GTK paints the new contents, but GDK clips it to the old position. The tooltip drawing code uses the size of the GDK window to draw the black border, tooltip is drawn as if the window didn't change size. - The ConfigureNotify arrives. Windows generally aren't invalidated here. - A MapNotify arrives - An expose for the window arrives, but the 'old' part of the window is antiexposed because we invalidated ourselves. So only the new part is drawn. The tooltip widget is not doing anything wrong. It is relying on not getting exposes before the window has its final size, which is fair enough. The new patch fixes this problem by updating the geometry information immediately when a n override_redirect window is moved or resized. The new patch also has an override_redirect flag and the is_viewable() optimization.
Created attachment 28639 [details] [review] patch
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
Moving this to 2.6, since we want to test it there first.
I'm not really sure what the changes to track the position of override redirect windows have to do with the other parts of that bug. Is the split between this and bug 113310 correct? But the patch looks correct and good to commit.
Ah, misssed the comment above about tracking the size.
Fri Jul 9 23:26:09 2004 Soeren Sandmann <sandmann@daimi.au.dk> * gdk/x11/gdkwindow-x11.h (struct _GdkWindowImplX11): Add an "override_redirect" bit. * gdk/x11/gdkwindow-x11.c (gdk_window_new): Set it here. * gdk/x11/gdkwindow-x11.c (gdk_window_move, gdk_window_resize, gdk_window_move_resize): Update the local size/position cache immediately for override redirect windows. * gdk/x11/gdkwindow-x11.c (show_window_internal): Invalidate newly mapped child and override redirect windows.