Re: MASKING/COVERAGE ETC...

THIS IS A RESEND TO THE GROUP.

On Mon, Aug 6, 2012 at 11:00 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Mon, Aug 6, 2012 at 9:24 AM, Bob Holmes <rangsynth@gmail.com> wrote:
>
>> I am just now actually implementing this so I have this way of drawing
>> where the lines are rasterized with a mask value. Sometimes per pixel
>> but also for the width of a polygon for example. Like in AGG or
>> similar to masking maybe in libpixman.
>>
>> So I see in agg that they combine the masking for operators like SrcIn
>> to actually use the mask value to affect the output with the
>> destination. This does not make sense.
>>
>
> Depends on what you call masking. Is it alpha or luminosity masking? Most
> people want luminosity which is more than simple src-in.
>
>
>>
>> Seems to me that if you have a masking value that it should simply be
>> combined with the alpha value of the source color before the blending
>> step. In addition to this a global alpha value could also be included
>> in this step.
>>
>
> I'm unsure if we call out when masking happens...
>
>
>>
>> For modes like DstIn masking would thus have no effect.
>>
>> The blend function for RGBA excepts a value from 0 to 255.
>> I also have a global alpha value which affects all alpha.
>>
>> My theory is that no matter the blend mode or combine mode that source
>> pixels can simply have the alpha adjusted by multiplying with both
>> global alpha and the mask value, which can optimally be combined prior
>> to actually calling into the blenders.
>>
>
> No, if you have grouping, you can't simply redistribute alpha. That will
> make the graphics interact with each other which is usually not desired.
>
>
>>
>> What do you think? The specification is only touching on coverage as a
>> function of ource and destination alphas but makes no mention of
>> coverage as it would be affected by a masking value, such as the
>> masking value that a polygon mask might output.
>>
>
> Yes, I will talk to some people and will update the spec.
>
>
>>
>> In libpixmap they have per channel masking. Is this concept also being
>> planned to be included in the specification?
>>
>> No, the current formulas treat all channels the same.
> If there's a need, we can add it later. If at that point, we have
> programmable blending and compositing, those will be address that use case.
>
> Rik
>
>