On Thu, 06 May 2010 10:30:25 -0400, Adam Jackson a...@nwnk.net wrote:
On Wed, 2010-05-05 at 15:45 -0700, Keith Packard wrote:
On Wed, 5 May 2010 16:25:28 -0400, Adam Jackson a...@redhat.com wrote:
+
+/* if we don't need to backfill, we're done */
+if (pWin-backgroundState != BackgroundPixmap)
+return pPixmap;
+if (pWin-background.pixmap != None)
+return pPixmap;
+
Presumably this pixmap is being allocated for the window manager frame,
not the application itself. This isn't looking at the background for the
application, just the frame.
Oh, gross. If I'm reading this right, miPaintWindow clips by children
(not IncludeInferiors, and called after map and validate), which means
if you map an entire subtree at once, the bg=None regions poke through.
Is that accurate?
I'm not totally convinced that's required by the protocol, but I can
imagine it being required by applications. It's easy enough to check,
and the tree walk will almost certainly be faster than the blit.
If background None is specified, the window has no defined background.
When no valid contents are available for regions of a window and the
regions are either visible or the server is maintaining backing store,
the server automatically tiles the regions with the window's background
unless the window has a background of None. If the background is None,
the previous screen contents from other windows of the same depth as the
window are simply left in place if the contents come from the parent of
the window or an inferior of the parent; otherwise, the initial contents
of the exposed regions are undefined.
The first offers plenty of wiggle room here, the second, alas, the
second appears to require the tree walking plan. And, yes, lots of
applications depend on the contents being copied from the screen. In
particular menus often get mapped using background None and no contents
so that the first view seen is of the painted menu and not an empty
background.
Let me know if you're planning on providing a new patch for this.
--
keith.pack...@intel.com
pgpcXRqNfCB6P.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
