[cairo] [PATCH] [API] Support component-alpha.

[Chris Wilson]

Excerpts from Soeren Sandmann's message of Tue Oct 20 14:46:51 +0100 2009:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > So we need component-alpha support on patterns internally, so present
> > the same power to the users as well. For indeed, they may well be
> > dreaming of demonstrating sub-pixel geometry masks...
> 
> Would this be expected to be useful for gradients, or would it be
> considered some crazy thing you could set if you knew what you were
> doing?

Your right in that the principal use case is to allow sub-pixel surface
masks to be supplied. I can see gradients being interesting as well, but
the scenarios I can envisage for using gradients all seem to imply that
the user needs to supply the complete sub-pixel mask anyway. I'm probably
just not being imaginative enough.
 
> I could sort of see a gradient from say 
> 
>         (ffff, ffee, ffdd) 
> 
> to 
> 
>         (0022, 0011, 0000) 
> 
> being interesting as a component alpha mask, but the documentation for
> the proposed API implies that no filtering or gamma correction would
> takes place, which would result in color errors. And expecting users
> to compute pixel values from a gradient is not really in the spirit of
> cairo.

Hmm, I can appreciate that using a per-component mask complicates
everything, but how does this actually differ from cairo/pixman
currently for normal gradients?

At the moment there are a few bugs in Cairo where a per-component glyph
mask is being generated, but that information is not being passed along
to the rasteriser (the most obvious example is fallback glyph rendering
for xlib). The question simply becomes: can we define how per-component
alpha masks are supposed to operate and so be exported to users?
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre