[cairo] Alpha masks

[Keith Packard]

Around 16 o'clock on Jan 6, Owen Taylor wrote:

> I don't think implies that we have to have some generic operator that 
> exposes the drawing equation directly; backends need higher level access
> so they can avoid generating a million temporary surfaces and treating
> everything as an image.

We can simultaneously expose the primitive operation along with putative 
'convenience' functions which actually plug into higher-level backend 
functions directly; there's no need to model the implementation on the 
formal specification.

Providing access to the whole stack of operations allows applications to 
reimplement whatever portion of the operation is necessary while still 
gaining access to at least some level of acceleration.  

I think the lessons of the core X protocol is relevant here -- the
geometric operations could not be replicated in the client without
performing the whole sequence of operations there.

> And I don't think we have to have expose full generality in every
> operand of the drawing equation. What does it mean to have a gradient
> as a mask?

(Actually, I've used gradient masks several times.  If you look at my 
replacement for the 'gumby' cursor, you'll see a gradient mask applied 
across the image to make it less translucent near the pointer and more 
translucent further away)

> fill(), stroke(), show_text(), show_surface_mask() strike me as very
> consistent operations. The mask is explicit, the other arguments
> implicit. show_surface() is an oddball operation, but almost certainly
> necessary.

Using cairo_pattern_t instead of cairo_surface_t for the primitive used for
show_surface_mask provides all of the functionality of the underlying Plan
9 compositing model.  Whether we also provide cairo_show_surface_mask is a 
different question.

Before we get much further in this discussion, I think we really need to
address the clip operand and it's interaction with compositing operators
for which the alpha value in the source doesn't limit the affected pixel 
set in the destination.

Carl and I discussed this a bit last year and came up with a very simple 
proposal, which is well defined, but may not be as useful as we'd like.  

That is to simply treat the 'clip' as another part of the 'mask' and 
accept the fact that areas beyond the clip will be modified in the 
destination.  All of the operations remain well defined, although their 
utility may be strongly compromised in some cases.  Do an 'IN' operation 
with an empty clip and the entire destination surface will be erased.

We can take advantage of our existing rectangle-set clip computations to 
make the 'outside' parts more efficiently modified; applying (0,0,0,0) 
to the inverse of the rectangle-set clip area.

Is the ease of specification and consistency in the API worth the 
degredation of expected functionality?  Does anyone have an alternative 
specification which works for the full range of alpha values?

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050106/ddfc017e/attachment.pgp