After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141380 - Don't draw behind child windows
Don't draw behind child windows
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other Linux
: Normal normal
: Small fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-04-29 11:23 UTC by Soren Sandmann Pedersen
Modified: 2005-03-28 20:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to not draw behind mapped child windows (2.77 KB, patch)
2004-04-29 11:24 UTC, Soren Sandmann Pedersen
none Details | Review

Description Soren Sandmann Pedersen 2004-04-29 11:23:31 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.
Comment 1 Soren Sandmann Pedersen 2004-04-29 11:24:39 UTC
Created attachment 27202 [details] [review]
Patch to not draw behind mapped child windows
Comment 2 Matthias Clasen 2004-04-29 13:57:46 UTC
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 ?
Comment 3 Soren Sandmann Pedersen 2004-04-29 16:48:26 UTC
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.
Comment 4 Soren Sandmann Pedersen 2005-03-28 20:28:54 UTC
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.