[cairo] Proposed simplified replacement for Cairo compositing operators.

[Bill Spitzak]

On Thursday 21 October 2004 10:26 am, Carl Worth wrote:
> 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.

That's a good idea. I thought the main difference is that the clip 'k' does 
not contribute to 'a' and all the functions are changed from C=f(a,A,b,B) to 
C=f(a,A,b,B)*k+B*(1-k).

At least that was my understanding, your explanation of "IN" below implies 
that you want Cairo to act exactly like I described except the additional 
Porter-Duff functions are provided.

> 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.
>
> 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.

Okay, I think I see the confusion. Basically you are allowing an OP to modify 
outside the clip path, in fact all the way to the edge of the surface.

I (and I think a lot of other people) disagree with that design. It would be 
nice to be able to set a clip path and be able to assumme that some code you 
call cannot draw outside it (barring illegal things like extra grestores or 
reinitializing the state). In particular this would allow a toolkit to use 
Cairo clipping to implement arbitrary-shaped widgets and display areas.

So I figured that clipping was done as a final step. But if you assumme 
antialiased clipping it seems like the best implementation would be to put 
everything into a single function. My proposal was to simplify that function 
by limiting it to a subset where the source alpha and clip can be 
premultiplied. The main advantage I see is that the bounding box of the 
altered pixels is known irregardless of the OP and that drawing rectangles 
inside rectangular clips could possibly be accelerated more.

> 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.

Invert path means that the area between the path and the clip is filled, so 
it does not go to infinity, only to the clip.