[PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> This could work if your layer was _completely_ trivial, or if you were
> extremely careful about unwinding your layer's state. Merely changing
> the wrapping convention isn't going to make it easy to, say, disable
> glamor on the fly.

This happens a lot more with GCOps where we want to unhook damage from
the rendering chain when the target doesn't have anyone monitoring
it. Of course, if we move those to the screen, then that's not going to
happen anymore.

> That sounds reasonable, though I might like to see an example of such a
> layer when we do this. I can imagine something like a 'trace' layer
> that lets you dump interesting bits to the log, for example.

The randr shadow code sticks itself in the block handler chain,
depending on whether the screen has a shadow or not; I think it ends up
at the right spot these days, but it's dicey.

> I think changing the wrap chain is likely to be rare enough to prefer
> SOA.

Bikeshedding, of course.

> The "call down" convention would need to know to scan ahead to find
> the next non-null fptr for the slot either way, but that's not really
> different from the current model where some slots can be null at the
> bottom.

Hence my hack of filling in the pointers between the slots which are in
use; you just call the one below 'your' entry.

> So... seems plausible. Maybe try the experiment with GCOps first before
> blowing up the whole Screen?

Seems reasonable. The hard part to me seems to be coming up with a
complete list of 'layers', or at least complete enough for a start. I
don't want to have to reallocate these on the fly...

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170302/0f70bec5/attachment.sig>