Render spec clarification

[Soeren Sandmann]

Adam Jackson <ajax at nwnk.net> writes:

> On Mon, 2008-10-13 at 11:19 -0700, Keith Packard wrote:
> > On Mon, 2008-10-13 at 13:50 -0400, Adam Jackson wrote:
> > > "like a copy" semantics of Option B to make
> > > the results predictable.
> > 
> > The core protocol uses 'like a copy' for CopyArea/CopyPlane. Actually
> > creating a copy would be fairly simple inside the Render code -- just
> > make a copy of the destination and use that as whichever source operands
> > match the destination.
> 
> Either or both source operands, remember.

If the only real use of src/mask=dst is to support scrolling, then
maybe XCopyArea is good enough. The only real drawback I can see is
that XCopyArea is then one of the only remaining legitimate uses of
GC's.

Considering the GraphicsExpose issue below, this is probably a vote
for BadMatch. Clients can always make a copy themselves if they need
the feature. I'm not strongly opposed to like-a-copy though.

> > > The other possibly unpleasant bit about Option B is it introduces more
> > > cases where the server will need to do significant allocation to satisfy
> > > rendering.  Probably not a huge deal, but worth noting.
> > 
> > A pain, to be sure.
> > 
> > If we do this, we would want to make sure the driver could recognize
> > scrolling cases and make those work correctly. And, make GraphicsExpose
> > events actually work too.
> 
> My thinking there was that we'd just smash onto the CopyArea path like
> we do already.  Technically (a SRC b) is more general than a plain blit
> since they can be different Picture formats pointing to the same Pixmap,
> but that seems like something we should just not allow for the scrolling
> loophole.
> 
> I get what GraphicsExpose events are supposed to be for, but not really
> how the region is defined.  It does seem like CopyArea's returned region
> is approximately the same thing though.

Unfortunately it's more complicated than that because Render has
repeating pictures. Suppose a repeating picture points to a partially
obscured window; then the GraphicsExposed region must be a repeated
copy of the hierarchy clip. Repeat here can be normal, reflect or pad
and each will need to be handled differently by the GraphicsExpose
code.

Clipping is already quite complicated in pixman, so if possible, I'd
prefer to avoid GraphicsExposes. I don't see using window sources as
interesting except in compositing managers where the pixels are
guaranteed to be available.


Soren