[cairo] Clip region problems

[Owen Taylor]

On Wed, 2005-05-18 at 13:29 -0700, Keith Packard wrote:
> On Wed, 2005-05-18 at 15:49 -0400, Owen Taylor wrote:
> 
> > I think this is clearly the semantic we want. The problem is that 
> > libpixman and RENDER don't work that way. 
> 
> I think the right answer is 'it depends'.  Render, by creating an
> intermediate object (Picture) permits either semantic by allowing
> multiple Pictures for a single Drawable.
> 
> > For A => B we temporarily clear the clip on A when using it as a source.
> 
> Or, we can simply define the backend semantics to not clip the source,
> the xlib Render backend would then need to create separate picture
> objects for source and destination operands.

That definition is there already. 

The temporary clear of the source region is done in the Cairo pattern
convenience functions that are shared between the xlib and image
backends (Probably also xcb, glitz, since those fall into the render-
semantics camp as well. Though it wouldn't sort of suprise me if glitz
didn't implement RENDER source clipping.)

> A more complete solution would include a clip region in the pattern
> object.  It would, of course, be nice to share these somehow saving
> ourselves a picture object and ancilary region.

Do we have any reason to think that source clips are useful? If not,
then putting them in the pattern object sounds like overcomplication.
(And causes huge implementation difficulties for many backends.)

The whole idea of a source clip has some funny interaction with
the idea of "extend" modes as well. I think what we decided for
RENDER is that we first determine the source pixel in the source 
image and then use the source clip to determine original vs. 
transparent for that. Which is logically consistent, but sort of
violates the reasons that you want extend modes at all.

> > But for A => A we need to "fork" the input surface when operating from a
> > surface to itself with a clip. (Create another Picture really.)
> 
> I guess the question is how the PDF, Quartz and Win32 backends might
> deal with separate input/output clip regions.  If they already have this
> ability, then we're all set.  Otherwise, we should consider what
> reasonable subset of the complete functionality is efficiently
> supportable.

To quote the Win32 docs: "BitBlt only does clipping on the destination
DC."

I'd imagine that's standard for most graphics systems.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050518/66a3c26b/attachment.pgp