Render spec clarification

[Adam Jackson]

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
-------------- 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/94506aa2/attachment.pgp>