[cairo] Proposed simplified replacement for Cairo compositing operators.

[Carl Worth]

On Wed, 20 Oct 2004 22:02:15 -0700, Bill Spitzak wrote:
> As per the conference call, I tried to trim down the PorterDuff operators to 
> ones that don't modify where alpha=0, and show how to emulate them. This grew
> into a much more detailed description:

Bill,

Thanks so much for putting together a detailed description here. This is
a great start for documenting the eventual cairo imaging model.

I'm not ready to give a complete evaluation yet, but one thing I would
like to see is similar description of the current model, (or at least
the diff that would result if we had such a description). That would
help me understand the scope of change in the proposal.

> The primary purpose is so that the path, clip, and source alphas can be 
> unified *before* the compositing operation. This makes the per-pixel 
> composite function as simple as possible. It also means the bounding box of 
> changed pixels of all operations is the same.

I'm still unclear on both of these points.

First, the current backends are built around a fundamental operator in
which the destination values are computed according to the equation:

	destination = (source IN mask) OP destination

where OP is any Porter/Duff operator.

Cairo uses this by constructing "source" from either a single color or
from a pattern (eg. an image or a gradient). The "mask" operand is
constructed from the current path and the clip (if any). So, in the
current model, path and clip are already unified before the backend
composite call.

We could rework the backend interface around a simpler operation:

	destination = source OP destination

which would then require the source pattern to be unified with the path
and clip before the final composite, but I don't see why this wouldn't
still work with all Porter/Duff operators. So I don't see the advantage
here. It's quite likely I'm just misunderstanding though.

Second, regarding bounding boxes. The "src IN mask OP dst" equation
above is valid, but the current implementation is actually broken. For
example, if OP==IN, the current bug causes the regions outside of the
bounding box of mask to be unchanged. In fact, they should be
cleared. This seems like an easy bug to fix.

So, in the current implementation, some operations have effects that
extend infinitely away from the limits of the source operands. Your
proposal introduces an invert-path operation. This doesn't actually help
to buond the operations, since it instead makes the source operands
themselves unbounded.

Again, I probably just need some help to understand this better.

-Carl