Render spec clarification

[Pierre-Loup Griffais]

On Monday 13 October 2008 17:01:57 Adam Jackson wrote:
> * PGP Signed by an unknown key
>
> Right now Render is sort of vaguely defined when any of (src, mask, dst)
> point to the same underlying drawable.  This is not necessarily just
> when they're all the same Picture, although that's certainly a special
> case.
>
> I'd like to have this clarified, since otherwise it becomes essentially
> impossible for something like shatter to do the right thing,
> particularly in the face of transforms.  Anholt pointed out a legitimate
> use of (src IN src OP dst), which is to coerce src to premultiplied
> alpha.  So I think the only thing we need to clarify is when dst is the
> same drawable as one of the other operands.

Agreed.

>
> I can think of two possible resolutions, and I don't care particularly
> strongly about which one we go with, but I'll throw them both out for
> discussion:
>
>     Option A: mask==dst and src==dst are just not allowed, and we throw
>     BadMatch
>
>     Option B: when either of the above are true, the implementation must
>     act as though mask and src are constant pixel sources for the
>     duration of the request (ie, dst is copied aside internally to a
>     scratch picture, and the scratch is used as the logical source or
>     mask and then destroyed at the end of the request)
>
> The former is certainly way simpler, but might break some existing
> application.  Maybe?  I can't imagine anyone being crazy enough to do
> this, but then there's lots of crazy people in the world.

Agreed that it's the simple and logical way. On the other hand, I also think 
it's also a bit too late to change it that way: gtk-window-decorator from 
compiz, plasma from KDE4 and the RENDER back-end of Enlightenment DR17 all 
heavily rely on Src==Dst Composite operation (with regions that don't overlap, 
no transforms, no filters, so no room for bad behaviour on the server side I 
think). The first two alone probably span more than 90% of the current X 
userbase; I don't think option A is the way to go.

 - Pierre-Loup

>
> Thoughts?  If nobody has a strong argument for option 2 I'll go ahead
> and update the spec (and implementation) for option 1, on grounds of
> parsimony.
>
> - ajax
>
> * Unknown Key
> * 0xA0ECD0D3