# [cairo] Redoing SOURCE and CLEAR

Owen Taylor otaylor at redhat.com
Wed Aug 17 15:13:05 PDT 2005

```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:

(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);

CAIRO_TARGET_CAIRO_ALPHA,
target_width, target_height);
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_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
```