On Apr 30, 2013, at 9:56 PM, "Robert O'Callahan" <rob...@ocallahan.org> wrote:
> On Wed, May 1, 2013 at 4:11 PM, Andreas Gal <g...@mozilla.com> wrote: > I wonder whether we should focus on one fast GPU path via GLSL, and have one > precise, working, I-don't-care-how-slow CPU fallback. > > I agree that should be our top priority, and it may not be worth doing CPU > SIMD at all. But if we can get it cheaply via Skia or somewhere else, maybe > it's worth having. I didn't mean to imply CPU SIMD should be a priority. > > As for the filters on GLContext, I wonder whether thats really the best > approach. Don't most filter applications want to be injected into the shader > pipeline instead? We would have to be able to compose filters for that and > generate a composite GLSL program from that. So for example we want a > BGRXTextureLayer, with Mask3D, with ColorMatrix, and we want GLSL source > generated from that. So isn't really what we want a GLSL shader program > generator (and cache) that we give an EffectChain and that gives us back a > compiled shader? (with added effects including ColorMatrix, etc). > > That's a good point: for optimal performance with simple filters we need to > be able to combine the EffectChain with the filter. However I think adding > filters to the EffectChain is probably not the right way to do that, because > some filters require multiple passes with intermediate buffers and can't be > compiled to a single program. I think to keep basic compositing simple we > want an EffectChain to always compile to a single program. So I suspect the > best approach might be to pass the EffectChain as an additional parameter to > the GLContext filter implementation. Should we hide the temporary surface generation (when needed) within the API? GLContext::Composite(Target, Source, EffectChain, Filters) And if multiple shaders or passes are needed, we create a temporary surface on the fly and then do the final composite with the given EffectChain. Andreas > > 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
