- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 04 Nov 2011 00:14:09 -0700
- To: Alex Danilo <alex@abbra.com>
- CC: FX Taskforce <public-fx@w3.org>, SVG public list <www-svg@w3.org>
On 11/3/11 9:50 PM, Alex Danilo wrote: > 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/> > 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. > We came to a similar conclusion when working on a Canvas based web application, with "in" and "arbitrary pixel shader" being quite handy for drawing effects. Also, when working with filters, there are a lot of computers out there with relatively basic gpus; you can't expect the gpus of those machines to do much more than basic composite operations. Those machines will also have relatively slow cpus. -Charles
Received on Friday, 4 November 2011 07:14:41 UTC