GNOME Bugzilla – Bug 141380
Don't draw behind child windows
Last modified: 2005-03-28 20:28:54 UTC
When a window is invalidated, the area behind mapped child windows is also invalidated. This means that the area is drawn to the backing store even if it will never be visible. Normally only solid fills are drawn there and those are usually accelerated, but if they for some reason aren't, the X server spends a lot of time doing software fills that will just be thrown away. On my video-ram-starved laptop this patch makes the time spent in fbSolidFill() drop from 24% to 14% (of the system-wide CPU-usage) during opaque resize of Nautilus windows.
Created attachment 27202 [details] [review] Patch to not draw behind mapped child windows
Is this always a win, or are there cases involving accelerated fills and many subwindows, where it would be considerably cheaper to just fill everything, like the current code does ?
With the assumption that an accelerator is infinitely fast (which is actually not an entirely unreasonable assumption, imo), the current code will be faster because it won't have to remove the invalidated areas from the parent window. However, gdk_window_invalidate_maybe_recurse() is just noise on the profile anyway and this patch didn't change anything significant about it - it is on the order of 0.8% - 1.0% in both cases.
Mon Mar 28 15:13:42 2005 Søren Sandmann <sandmann@redhat.com> * gdk/gdkwindow.c (gdk_window_invalidate_maybe_recurse): Don't invalidate areas that are covered by mapped input-output child windows. Bug 141380.