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

[Adam Jackson]

On Wed, 2017-03-01 at 15:16 -0800, Keith Packard wrote:
> > Adam Jackson <ajax at redhat.com> writes:
> > 
> > > For the real wrappers, I think we can start with some requirements:
> > > 
> > >  1) Remove wrappers at any time.
> > > 
> > >  2) Insert at the 'right place' in the chain, independent of where the
> > >     wrapping happens.
> > > 
> > >  3) "impossible" to get wrong, so no cult-n-paste code
> > >     needed for every step of wrapping
> > 
> > I'm not really sold on the need for 1. Where would that be useful?
> 
> Right now, the only place you can unwrap is while the wrapper is
> running. That means you can't decide to stop catching a pile of screen
> funcs all at once, you have to unwrap each one as invoked. Ick.

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.

> > I don't understand what you mean by 2.
> 
> I'd like to be able to insert a set of wrappers after the server has
> started, but currently there's no way to make sure they get into the
> chain at the right place. What we end up doing is adding wrappers during
> server init and leaving them in place.

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.

> Then, DIX would use screen->CreateGC[0], glamor would use
> screen->CreateGC[2], and when glamor wanted to call down to a software
> layer, it would use screen->CreateGC[3].
> 
> I'm not sure the ordering is correct or complete, and of course we could
> use AOS instead of SOA for the function pointers.

Depends what we optimize for. SOA's likely to be more dcache-friendly
since all the fptrs for a single call chain will end up in a small
number of cachelines that won't alias. On the other hand AOS makes it
(marginally) cheaper to wrap in/out on the fly. I think changing the
wrap chain is likely to be rare enough to prefer SOA. 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.

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

- ajax