[cairo] Blend modes take 3

[Benjamin Otte]

Hey,

Thanks for the thorough analysis of this. The fact that I have thought
about all the things you bring up actually makes me more confident I
didn't do something stupid. :)

On Sun, Oct 19, 2008 at 1:54 AM, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> This sort of suggests that instead of adding all the PDF blend modes
> as separate operators, they could instead be given as modifiers to an
> existing operator. [...]
> This is substantially more general approach than just adding the
> blendmodes alongside the existing operators. If hardlight is useful,
> you would think that it's just as useful with the "IN" operator.  It
> seems to me that this way of thinking of blend modes would be more in
> the spirit of the Render extension and more of a Right Way to do it.
>
> Whether it's useful and/or worth the trouble, is another matter.
>
I have thought about this for a while. First, here's some observations:
1) Quartz2D I think is the only API that has seperate operator and
blend mode. SVG explicitly makes blend modes operators. Most APIs
don't support Porter/Duff at all (including PDF and Flash), so for
them it doesn't matter.
2) It is possible to get every combination of operator/blend mode
using masks/clipping and push/pop_group() magic, should you want to
use IN with MULTIPLY.
3) If you want the most general approach, you'd end up with 4^4 = 256
operators - 0, S, D, f(S,D) applied on each of 0, S, D, SxD -  and an
infinite amount of functions.

So the task is to limit the infinite functionality to a sane subset.
This both goes for the backends (you want to ideally implement it in
SVG and PDF without fallback images) as for the API users, who want to
have the functionality they need available to them.
As I have not seen anybody make use of both operator and blend mode, I
decided to go with making the blend modes operators for ease of use
and implementation. If there however are lots of people doing this (I
don't use OS X, so no idea) or it's expected to happen in the future,
I'd agree we should change it now and do it the hard(er) way.

> Two new operators, Invert and Subtract, are not in the PDF spec. They
> were introduced by Flash
>
Note that I did the same extended-blend tests that are in the Cairo
testsuite to all Flash-supported blend modes using SWF files, so I am
pretty sure the implementation is correct. (The test files will of
course enter the Swfdec testsuite once I add blend mode support.)

> Neither of these operations are specifiable in the Porter/Duff or the
> PDF framework. There is also no specification anywhere that I can
> find, not even in the SWF file format spec.
>
Yeah, I was quite surprised to find that Flash felt the need to add
some nonstandard blend modes of its own, as they neither exist in
Adobe's PDF or Photoshop nor anywhere else. So I was actually quite
uneasy about adding them as they couldn't be supported on any backend,
but I didn't find a way to get their effect using other blend modes.

> Maybe this one could be done by simply using the blending with white
> and using the Difference blend mode? Is there a way that Subtract can
> be made more regular?
>
Uh yeah, INVERT is of course just difference to white, so a simple
push/pop_group() and using the result as mask with a white difference
should take care of this.
I always stopped thinking about the blend modes when I couldn't come
up with a SUBTRACT replacement.

This leaves the question if we should add these blend modes for
supporting Flash and do tricks/fallbacks in the backends or if we
should tell Flash implementors to do tricks to simulate these blend
modes. I don't have a strong opinion there, but I guess I would leave
them in as they are already implemented in my code.

Cheers,
Benjamin