Re: minutes, 3 November 2011 FX Taskforce F2F meeting at TPAC 2011

Hi Alex,

From: Alex Danilo <alex@abbra.com<mailto:alex@abbra.com>>
Date: Thu, 3 Nov 2011 21:50:36 -0700
To: FX Taskforce <public-fx@w3.org<mailto:public-fx@w3.org>>
Cc: FX Taskforce <public-fx@w3.org<mailto:public-fx@w3.org>>, SVG public list <www-svg@w3.org<mailto:www-svg@w3.org>>
Subject: Re: minutes, 3 November 2011 FX Taskforce F2F meeting at TPAC 2011

Hi All,

Small comment relating to the compositing blend mode
discussion below:

--Original Message--:
<snip/>
    CC: I think we need to first make sure this is implementable, even
    on gpus and on mobile with reasonable performance

    VH: I would say the implementability is not a question, because we
    know filters are implemented
    ... and largely compositing is a shorthand for filters
    ... it might not be optimal and efficient though

    CC: we might need to make changes to the spec to allow efficient
    implementations

    <cabanier> correct. and we know compositing is working well on
    mobile devices since Flash is alreayd using it
<snip/>

The compositing blend modes _aren't_ shorthand for filters.
The filter model is basically a binary operator on two things that
gives you a result, and mostly implies that intermediate buffers
are required.

Batik, ASV etc. use intermediate buffers for generating
the output of the filter (we do too when implementing <filter>).

But the blend-modes as a property get rid of that requirement.
The rasterizer can apply the blend mode at polygon fill time, so there
is no need for any intermediate storage. Also, that implies it should
map to pixel shaders fairly easily.

For example, the blended gradients on top of video demo
I did a few years ago does the blend on the fly as part of the polygon
filler.

The main problem the blend operators solve is need for
intermediate buffering. There was a lot written up on this years
ago while it was being designed, not sure where to point at now.

I do think the actual blend operators will map well onto
GPU or S/W renderers, but P-D is another matter altogether. So as
was suggested before maybe we need to pull out the P-D
operators into a separate property. That would also allow
you to do something like an 'in' combined with 'color-burn' for
much better render control - and the P-D stuff really is orthogonal
to the blend functions anyway.

yes, I agree with you that there is a core difference between compositing and filters which access BackgroundImage. Trying to think back about the discussion we were having, I think I was trying to say that in both cases, you can compute the blended pixel value that is basically a combination of your source and destination.

As you point out, there is conceptually a src-over compositing at the end of the filter operation, so, for example, you cannot 'remove paint' from the background with filters, which blending would allow. With filters and the default painter's algorithm, the alpha value can only go up. With compositing, we are modifying the background image itself, we are not with filters where the background is just the input.

This said, I think what was going through my mind in that discussion is that a lot of effects we may want to do (such as an 'add' composite') would work very well in may cases where the background is fully opaque and you are not trying to 'remove paint'/decrease alpha of the destination. And from the notes, I think I was pointing out that filter implementations have shown that a lot of what is required for compositing is feasible, and I was not too worried about implementability.

Cheers,
Vincent