[RFC][PATCH] dix/composite: Update windows with automatically redirected children on demand

[Keith Packard]

On Mon, 27 Dec 2010 15:27:10 +0200, ville.syrjala at nokia.com wrote:

> So every time that the parent window's contents are expected to be
> up to date, the contents of the children should be copied immediately
> to the parent.

When using the parent as a source operand, this looks like a useful
change. However, when using it as a rendering target, any drawing will
be immediately overwritten with the next drawing by the application
unless the parent contents were copied back to the child.

So, I'd say we should look only at cases where we use the window
contents as a rendering source and ignore any rendering target
operations.

> Instead of trying to identify all parts of the code that have that
> requirement, add a simple hook into NotClippedByChildren(), which can
> perform the update process. Hopefully that should cover most of the
> cases, if not all of them.

It would be nice if this could work, but it's almost entirely
inaccurate:

 1) GetImage doesn't use NCBC
 2) CopyArea doesn't use NCBC when copying from the Root
 3) CopyArea doesn't use NCBC when copying from self
 4) ValidateGC/ValidatePicture use NCBC only when the clip may have changed

This seems like a job for the existing SourceValidate hook, which gets
called for CopyArea when src != dst (and also when src == dst when
damage is running), and also is called for Composite (all of the time).

(There aren't any out-of-tree callers to SourceValidate today, so we can
actually just fix the existing bug where damage calls SourceValidate
sometimes to patch-up the missing calls from CopyArea.)

I'd say a combination of SourceValidate and GetImage wrappers would do
the trick nicely here.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101227/c0dd5f37/attachment.pgp>