[Pixman] Going to land: Re: [PATCH 0/7] lowlevel-blt-bench test pattern parser

[Pekka Paalanen]

On Tue, 14 Apr 2015 17:15:10 +0100
"Ben Avison" <bavison at riscosopen.org> wrote:

> On Tue, 14 Apr 2015 09:36:38 +0100,
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Mon, 13 Apr 2015 18:42:45 +0100
> > "Ben Avison" <bavison at riscosopen.org> wrote:
> >
> >> On Mon, 13 Apr 2015 12:31:35 +0100,
> >> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >> > None of the existing tests has a solid mask for CA tests. I'm not
> >> > sure how much it makes sense.
> >>
> >> When you're in component alpha mode, mathematically the source and mask
> >> images are interchangeable. So you could implement over_8888_n_8888_ca
> >> by calling over_n_8888_8888_ca, and we already have a number of fast
> >> paths for operations of the latter form. (I'm not aware that Pixman is
> >> - yet - aware that it can make such substitutions, but I'm sure it
> >> could be added.)
> >
> > Hmm, yes, interesting, at least in the cases where the operator indeed
> > allows it... I don't know the operators by heart so I don't know if
> > there are any that wouldn't work like that. An idea to remember.
> 
> Having thought about it some more, and checked the source code (it's
> clearer in pixman-combine-float.c because the maths isn't obfuscated by
> the need to work in fixed-point) I'm going to retract the claim. Or at
> least restrict its applicability. (This demonstrates the danger of there
> not being anyone around to contradict me!)
> 
> The problem is that although alpha is considered independently for each
> colour component of the mask - so you just multiply the source red by the
> mask red and so on, I'd neglected the alpha component in the source
> image. Yes, because Pixman premultiplies the alpha into the RGB
> components, it doesn't directly affect the RGB output of the combined
> source+mask image, but there's a secondary output, a per-channel alpha,
> which affects the Porter-Duff operation. For example, with an OVER
> operation, the inverse of the per-channel alpha is multiplied into the
> existing value from the destination buffer before you add-saturate the
> combined source+mask into it.

Heh, I had a feeling there might be something like that, but couldn't
put a finger down where. :-)


> > So, can I take it that you gave your Reviewed-by for the whole series?
> 
> Yes.

Thanks! So that said, I will land this series on Thursday if no-one
complains.


Thanks,
pq