On Mon, 2008-10-13 at 09:00 -0700, Carl Worth wrote: > On Mon, 2008-10-13 at 11:01 -0400, Adam Jackson wrote: > > 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. > > So Composite with op==SOURCE couldn't be used for things like scrolling? > > That would make Render a very incomplete interface, wouldn't it? > > And we're sure that applications don't actually do things like that > already?
I would be very surprised, at least for uses outside of scrolling, since Render doesn't define what the result should look like. You either need to define a pixel walk order (which would constrain the implementation so hard as to make hardware acceleration without programmable shaders basically impossible, would make more interesting filters exasperatingly hard, etc.) or enforce the "like a copy" semantics of Option B to make the results predictable. > (Though I do agree taht actually using overlapping regions with > something like op==OVER must certainly never occur in practice > currently---since the current behavior cannot be useful.) Fair point. Can we think of a case like scrolling where we'd actually want alpha blending? Even (src IN mask SRC src) is kinda awkward, since the mask in general won't be pixel-aligned, so the results around the mask edges won't be what you want in any case if the source and destination rects overlap. I don't have a problem with defining a loophole for scrolling, as long as we're strict enough about proscribing transforms and masks and such. 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. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
