Blend modes take 3

[Soeren Sandmann]

Hi Benjamin,

> I've updated the patch again here at the hackfest, and as far as I'm
> concerned the patch can go in now. But I'd like you to ok it before I
> push it.

Overall, the separable blend mode stuff looks good, except for the
component alpha versions. Generally, the way to implement component
alpha is to first apply

        fbCombineMask (&s, &m);

then blend as normal, except using Channel(m) whenever you would
normally use Alpha(s). With that in mind, the blending in

        fbCombine ## name ## C 

needs to look something like this:

        fbCombineMask (&s, &m);

        result = d;
        fbByteAddMul (result, ~m, s, ida)

        result =
                (DivOne (Alpha (m) * da) << A_SHIFT) 
                (Blend ## name (Red (d), da, Red (s), Red (m)))
                ...;

Similarly in fbMultiplyC() and the non-separable blend loop. In
the Subtract macro there shouldn't be any combining with the
destination.

Other than that,

- I'd like to see one comment that explains how PDF blending works in
  general, then for each blend function just have the comment describe
  the blending, not the whole operation.

- There is a spurious while() in BlendOverlay().

- "Separable" is spelled like that, not "Seperable"

- There is a semicolon after while(0) in the Subtract macro

- I think the Subtract blend mode should be called something like
  FLASH_SUBTRACT since it is so weird and is not actually the inverse
  of Add.

I did not yet look at the non-separable blend modes, except that I'm
wondering whether the Lum macro has sufficient precision when blending
in 64 bit mode?

> We decided to prefix the non-seperable blend-modes with "HSL" to avoid
> the confusion with the SATURATE operator. Otherwise I've used the
> exact naming that is used in the ISO32000 PDF spec.

Sounds good to me.


Søren