[cairo] Proposed simplified replacement for Cairo compositing
spitzak at d2.com
Fri Oct 22 11:03:55 PDT 2004
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:
> 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
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.
More information about the cairo