On Apr 30, 2013, at 10:28 PM, Andreas Gal <g...@mozilla.com> wrote: > > 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.
On a second thought I think this should really live in gfx/layers/opengl, not on GLContext. I just filed bug 867460 to move all the layers-specific shader program stuff out of gfx/gl (which we should probably slim down and mostly eliminate over time). Andreas > > 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
