Render spec clarification
Adam Jackson
ajax at nwnk.net
Mon Oct 13 08:01:57 PDT 2008
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.
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. The latter is
slightly more complexity to implement, although it can all be hidden way
up in DIX code. Either way leaves the drivers with a pleasantly strict
view of the world where all three operands are distinct.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081013/676fab8e/attachment.pgp>
More information about the xorg
mailing list