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.

Alex

Received on Friday, 4 November 2011 04:51:06 UTC