[cairo] Alpha masks
Keith Packard
keithp at keithp.com
Thu Jan 6 13:38:16 PST 2005
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
More information about the cairo
mailing list