- From: Vincent Hardy <vhardy@adobe.com>
- Date: Tue, 8 Nov 2011 16:29:57 -0800
- To: Alex Danilo <alex@abbra.com>, FX Taskforce <public-fx@w3.org>
- CC: SVG public list <www-svg@w3.org>
- Message-ID: <CADF0317.208F4%vhardy@adobe.com>
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
Received on Wednesday, 9 November 2011 00:31:17 UTC