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 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg