[Pixman] [PATCH 0/7] lowlevel-blt-bench test pattern parser

Ben Avison bavison at riscosopen.org
Tue Apr 14 09:15:10 PDT 2015


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.

My statement about being able to exchange the source and mask images is
true, but only if the alpha component is 1 in both images. For example,
over_0565_n_8888_ca or over_x888_n_8888_ca where (in both cases)
n.a == 1 would both be suitable candidates for exchanging the source and
mask.

For the avoidance of doubt, the Porter-Duff and PDF combiners are all
just binary operators, defined in terms of one source and one destination
image. Whenever Pixman talks about unified or component alpha operations,
it's just concerned with how the source and mask images are combined into
the effective source image for the fundamental combiner. It just happens
to be more efficient in most cases to do both the source/mask and source/
destination calculations at the same time, rather than writing out the
intermediate image into a buffer somewhere.

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

Yes.

Ben


More information about the Pixman mailing list