Composite Manual mode and clipping

[Keith Packard]

Right now, composite does not affect clipping of sibling or parent
windows. That means when you redirect a window, the parent and siblings
continue to be clipped in the position of the window. Which is a bit
odd, considering that the redirected window doesn't 'really' exist on
the screen at all.

This clipping does make sense for automatic redirected windows where the
server paints the redirected window to the parent without client
intervention; siblings and parent drawing needn't affect the child as it
will always be correctly redisplayed by the server.

Where this clipping is broken is when the parent window is not the root
and the window is manually redirected. Damage to the window tree
containing the redirected window will not send expose events to the
redirected window (it's redirected, after all). Damage to the window
tree where the redirected window is present is not delivered to the
parent window either; it is covered by the child, and so has no visible
region to be damaged.

The result is the application with redirected subwindows cannot keep
their window contents updated correctly in the presense of other window
configuration; no expose events are sent that describe where the parent
needs to be repainted with the contents of the redirected child.

The solution may be as simple as including the redirected child region
in the parent clip list; this will end up sending damage events to the
parent. It will fail when only a subset of the parent's children are
redirected though; there will be no way to detect that the areas of the
child on top of sibling windows has been damaged.

I don't think the current behaviour is useful; it makes sub-window
compositing impossible. I'm not sure the simple solution of including
the child area in the parent clip list is viable in all cases either; it
makes compositing just one child impossible as other siblings will
continue to block expose information where they overlap.

Feedback is welcome at this point; I'd like to try and work out some
ideal semantics and then temper those with a dose of implementation
reality so that we can provide suitable services for applications
without destroying our current performance.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070226/276969b2/attachment.pgp>