roc and I took the discussion offline and there is another option that might be possible:
Instead of creating a separate content effect path and compositor effect path, we could add support for effects to Moz2D, and then implement our compositor via Moz2D. In this world, there would only be 2 backends to Moz2D, Skia/SkiaGL and D2D. Both Skia/SkiaGL and D2D support basically all the effects and filters we want. Where D2D is not available, we can fall back onto SkiaGL via ANGLE, or if all else fails Skia (CPU only, old XP). The compositor is implemented based on Moz2D and has no backend-specific code. layers/opengl layers/d3* can be deleted, mostly. gfx/gl can be deleted as well, for the most part, minus for what SkiaGL needs to bind to the platform GL code. roc points out that we would have to add a couple extensions to Moz2D, including gralloc, tiling, component alpha, and 3D transform. The upside would be that there is exactly one path for effects/filters for content and compositor. To add new filters or to maintain code or features we don't have to go and update 3 different shader representations in 3 text files for 3 platforms plus the content fallback path. Almost all of our gfx code will live above the Moz2D layer, and is platform independent. Since both D2D and Skia/SkiaGL already support (and accelerate) all the filters we want to implement, this exercise would be mostly code deletion and writing some glue code around D2D and SkiaGL. What do people think? Andreas On Apr 30, 2013, at 10:36 PM, "Robert O'Callahan" <rob...@ocallahan.org> wrote: > On Wed, May 1, 2013 at 5:28 PM, Andreas Gal <g...@mozilla.com> wrote: > 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. > > It certainly should be hidden within the GLContext filter implementation. > That probably needs to live somewhere under gfx/gl, since Moz2D will need > access to it and Moz2D doesn't depend on layers. > > 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
