[cairo] Redoing SOURCE and CLEAR

[Owen Taylor]

On Wed, 2005-08-17 at 13:35 -0700, Carl Worth wrote:
> On Wed, 17 Aug 2005 16:28:14 -0400, Owen Taylor wrote:
> > I'll skip adding commentary here and let the images stand on their
> > own.
> 
> Well, I'll comment on it then.
> 
> Fantastic work, Owen!
> 
> These pictures are exactly what I needed to convince myself we want
> the new equation. Under the new equation, the operator controls the
> interaction of source and dest, while the shape and clip are only used
> to restrict the behavior. As the images show, this provides consistent
> behavior across all operators, and unique results for each.

Hmm, I came to the opposite conclusion. There are some nice properties
of the new equation:

 - *Everything* is bounded by the mask
 - You can always interchange mask and clip for all operators (including
   SATURATE)
 - We only have two equations, not three
 - They behave more similar to CLEAR and SOURCE

But on the other hand:

 - The old DEST_IN is 

    "Cut this shape with scissors from the destination, 
     and use cut out portion"

   (TRIM might be a good intuitive name for it) The new DEST_IN is
   much less useful.

 - The old IN, OUT, DEST_ATOP aren't so intuitive, but if you 
   understand their inverses:

    DEST_IN: "Cut this shape with scissors from the destination, 
              and use cut out portion"
    DEST_OUT: "Cut this shape with scissors from the destination, 
               leaving a stencil"
    ATOP: "Overlay the shape as a shadow on the destination"

   Then you can reverse them:

    IN: "Cut whatever shape is represented by the destination
         out of src IN mask, and use the cut out portion"

   And so forth.

 - There is a nice relationship:

    "DEST_IN ADD DEST_OUT == DEST"
    "IN ADD OUT == (source IN mask)"

   (It used to be "IN ADD OUT == SOURCE", but now we've changed
   SOURCE...)

> And if the old behavior is ever useful, it looks like it would be
> simple enough to obtain with an extra CLEAR and some intermediate
> surface juggling, (even less juggling if we add the INVERSE_FILL rules
> at some point).

There's definitely some juggling ... in fact, you can't write 
code to do it at all, unless you know one or of the other of:

 A) the bounding box of the shape you want to draw
 B) the bounding box of the target surface

And even then, it gets really nasty without the group API;
making the simplifying assumption of a 1:1 CTM. I think for
DEST_IN, you'd want:

 cairo_set_operator (cr, CAIRO_OPERATOR_DEST_IN);
 cairo_paint (cr);

 mask = cairo_create_similar (target, 
                              CAIRO_TARGET_CAIRO_ALPHA,
                              target_width, target_height);
 cr2 = cairo_create (mask);
 cairo_move_to (cr2, x, y);
 cairo_show_text (cr2, "Hello World");
 cairo_destroy (cr2);

 cairo_save (cr);
 cairo_set_operator (cr, CAIRO_OPERATOR_DEST_IN);
 cairo_set_source_surface (cr, mask_surface, x, y);
 cairo_paint (cr);
 cairo_restore (cr);

Though this *does not* give correct results if you have a
non-pixel-aligned clip. You'd have to copy from the destination
to a temporary surface for this.

> How's the patch looking for this now? Is there a lot of churn needed
> to get the same level of optimization with the new equation?

The new equation is uniformly more expensive except for the case
where shape-in-clip is pixel aligned. While the code I have now isn't
*quite* final, it wouldn't be hard to finish it up.

> Or do we get to throw away a lot of the "unbounded clearing" code?

Some, not all. We still need to clear areas inside the mask but 
outside the source.

> So, I guess what we've done is to reduce "fill" to be conceptually
> equivalent to "clip; paint"? (with the exception of SATURATE). That's
> not unpleasant.

Including SATURATE, actually. It's just that clip; paint; is defined
differently for SATURATE.

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/20050817/7c9e61f5/attachment-0001.pgp