[PATCH 2/8] mi: miValidateTree based on paintable not viewable

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> +    if (pParent->realized) {

> +    }
> +    else if (pParent->paintable)
>          newVis = VisibilityFullyObscured;
> -        break;
> +    else {
> +        newVis = VisibilityNotViewable;
>      }

Non-viewable windows should always get NotViewable visibility, even if
they're saved in backing store, so the paintable clause is not needed.

>      pParent->visibility = newVis;
> -    if (oldVis != newVis &&
> +    if (pParent->realized &&
> +        oldVis != newVis &&

You need to send visibility events on unmap too, so this change is not needed.

>          ((pParent->
>            eventMask | wOtherEventMasks(pParent)) & VisibilityChangeMask))
>          SendVisibilityNotify(pParent);
> @@ -293,14 +303,13 @@ miComputeClips(WindowPtr pParent,
>               (oldVis == VisibilityUnobscured))) {
>              pChild = pParent;
>              while (1) {
> -                if (pChild->viewable) {
> +                if (pChild->paintable) {
>                      if (pChild->visibility != VisibilityFullyObscured) {

Hrm. Visibility has a well defined meaning in the core protocol. With
Composite, it's muddied because we've re-interpreted it to say pixels
are visible if the compositing manager might paint them to the screen
(in exposé mode or similar), which is to say if they're stored in the
pixmap for the window. I think that's a useful re-interpretation as the
goal of visibility is to tell applications when to draw their content;
applications which are FullyObscured or NotViewable should cease
painting to save resources.

With BackingStore Always, unmapped windows should behave the same;
visibility should be reported as NotViewable so that clients will stop
updating them.

However, in this code we're taking this computed value, and trying to
use it to help optimize region computations. So, we need to re-evaluate
every single use of visibility in this function and figure out how that
related to unmapped-but-paintable windows.

In this code, just setting the window visibility to NotViewable will
cause it to skip the optimized path. Similarly, the optimizations within
this loop to only modify window clips for un-obscured windows will be
skipped for sub-windows which are unmapped-but-paintable as well.

The rest of the changes in this patch seem fine, but there are
additional uses of visibility in mivaltree.c related to fully obscured
trees. My brain is now hurting from trying to reason about that code,
but the case in question is when a window moves from not viewable to
viewable but fully obscured. miTreeObscured just sets visibility bits,
so I think all you need to do is check for viewable in the else case:

            else if (pWin->viewable && pWin->visibility == VisibilityNotViewable) {
                miTreeObscured(pWin);
            }

That will change all of the subwindows to FullyObscured as appropriate,
without affecting their clip lists at all. I think that's going to work
correctly as the window clip list was empty before and should be empty
afterwards (otherwise miMarkOverlappedWindows would have allocated a
valdata for it).

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