[PATCH v2 5/6] composite: Support updating an arbitrary subtree

Keith Packard keithp at keithp.com
Fri Dec 31 14:00:43 PST 2010


On Fri, 31 Dec 2010 16:49:38 +0200, ville.syrjala at nokia.com wrote:

> WindowRec has a new member 'damagedDescendants' that is used to keep
> track of which subtrees need updating. When a window is damaged,
> 'damagedDescendants' will be set for all the ancestors, and when a
> subtree is updated, the tree walk can be stopped early if no damaged
> descendants are present.

I think this raises an interesting general topic - how much of the
current extension private stuff should get folded into the various DIX
structures?? We've got a bunch of non-optional extensions these days and
it might be a nice cleanup job to take their privates and move them.

> CompScreenRec no longer needs the 'damaged' member since the root
> window's 'damagedDescendants' provides the same information.

> Signed-off-by: Ville Syrjälä <ville.syrjala at nokia.com>

This seems like a reasonable optimization to me, reducing the cost of
having any CompositeRedirectAutomatic windows on the screen.

I'm not entirely happy with the name compChildrenUpdate, but given that
compWindowUpdate paints a window into its parent, I don't have a great
suggestion for an alternative name. One option might be to move the
painting code inside the loop:

compPaintWindowToParent(pWin)
{
        if (pWin->damaged)
                ...
                pWin->damaged = FALSE;
}

compChildrenUpdate(pWin)
{
        if (!pWin->damagedDescendents)
                return;
        for (pChild = pWin->lastChild ...)
                compChildrenUpdate(pChild);
                compPaintWindowToParent(pChild);
        }
        pWin->damagedDescendents = FALSE;
}

Or some such. Having two functions looping over the child list seems
ugly...

-- 
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/20101231/e4274e77/attachment.pgp>


More information about the xorg-devel mailing list