2013/5/1 Robert O'Callahan <rob...@ocallahan.org> > On Thu, May 2, 2013 at 12:37 AM, Benoit Jacob <jacob.benoi...@gmail.com>wrote: > >> I am not very familiar with the spec. Could you please give an example of >> such a filter that would absolutely require multiple passes? >> > > Two GLSL custom filters in a chain, where each filter has its own vertex > shader. If I'm not mistaken, doing those in a single pass would require > inverting the function expressed by the vertex shader of the first filter, > which is infeasible in general. >
Oh, sure --- /two/ custom filters. I was more wondering if there was a special kind of filter that by itself would require an intermediate surface. > > Another example is an SVG filter where the output of one primitive is > sampled by many other primitives (and not necessarily at the same pixel > coordinates, when <feOffset> is involved). You could duplicate that > primitive but in general that could lead to an explosion in the size of the > generated program. > For that, we could at least in some cases use Multiple Render Targets (MRT's) i.e. have a single shader that outputs to more than one color buffer. > > So if such filters exist in the spec, I would argue for taking them out, >> at least for now. You don't want portable-but-with-big-performance-caveats >> things in a 1.0 spec. >> > > SVG filters have already been around a long time and we can't break them > at this point. The vertex shaders for custom filters are quite powerful and > useful. We could prevent custom filters from being chained, but authors > would just work around it by nesting elements with one custom filter each, > leaving us in no better position. > Again, I didn't realize that we were talking about the chaining of multiple filters there. At least that makes it fairly explicity that this forces multi-pass rendering --- no surprise here. There already exist various ways to do multi-pass rendering (like, WebGL framebuffer objects), I was more concerned about something that would do so in a surprising way. > > >> I realize that we do have intermediate surfaces in our own compositor, >> but at least that's (for all I know) just an implementation detail, not >> something explicitly required by a spec. >> > > It's hard to implement group opacity without them. We discussed on IRC how > one could use custom shaders to eliminate intermediate surfaces, and that's > a cool idea, but there are tradeoffs involved if we start generating lots > of custom shaders (one per sequence of child layer types at least). Don't > want to prematurely optimize. We already do simple optimizations such as a > ContainerLayer with opacity and a single ThebesLayer child just pushing its > opacity down to the child, avoiding an intermediate surface. So we're only > talking about situations like a ContainerLayer with opacity that contains > several elements with animated transforms or scrolling, or a ContainerLayer > with opacity that contains Web content and a playing video. > > Looks like Bas's D3D blur code requires intermediate surfaces in some cases, too. OK, thanks for the explanation. Benoit > > Rob > -- > q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q > qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq > qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq > qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq > qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q > qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
