On Thu, 06 May 2010 10:30:25 -0400, Adam Jackson <[email protected]> wrote: > On Wed, 2010-05-05 at 15:45 -0700, Keith Packard wrote: > > On Wed, 5 May 2010 16:25:28 -0400, Adam Jackson <[email protected]> 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. -- [email protected]
pgpcXRqNfCB6P.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
