Blend modes take 3
otte at gnome.org
Thu Nov 13 08:48:04 PST 2008
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
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.
On Thu, Oct 23, 2008 at 11:11 PM, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> So far as pixman and Render are concerned, it seems like the INVERT
> operator can be trivially implemented with (white IN src) DIFFERENCE
> dest. If so, there doesn't seem to be a good reason for pixman to
> export the INVERT operator. Whether cairo should is another matter -
> personally, I wouldn't add it, but I'll let other people answer that
I switched swfdec to use it and it worked fine, so I removed INVERT
> If it would be really expensive, say involving reading pixels back
> from the X server, then I'd say add it, but if there is a fairly
> simple workaround, then maybe we can leave it out and revisit the
> question later.
I've asked people here at the hackfest and nobody knew a solution to
it. So I left it in.
> Here are the things that I think should be fixed before merging:
> All the blend loops could then be defined by simply
I've done that and saved roughly 50% of the code. The code looks way
cleaner to me, too.
> Also, I think we need component-alpha versions of the blend modes. As
> you noted on IRC, this should be a mostly a matter of writing an
> FbBlendFuncC macro.
I did this, too.
> Could we just use floating point here? The integer math above is quite
> I'll look at the separable blend modes later, but from a quick look it
> seems like it could benefit from using floating point in various
> places too.
I've switched SoftLight to use doubles now, but left non-seperable ones alone.
More information about the xorg