This sounds like an awful lot of work, a lot more than some glue code and code deletion. It sounds like you are proposing to make Moz2D pretty much a general purpose 2D and 3D graphics library, touch (to some effect) the whole of the graphics code, and switch to using new libraries which have not been tested for this purpose and at this scale. All for implementing a new feature which is only "fairly" important. Given how much time/pain the shadow layers refactoring cost and the time/pain it has taken to get SkiaGL going, this all seems like quite a risk.
Surely there is a less drastic way to implement the filters? Perhaps it is worth refactoring the graphics code in this way, but that seems like a different conversation. > 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. At present, and I believe this is a long term goal, Moz2D doesn't know about any of the other Mozilla graphics. So hiding API within GLContext rather than layers won't help. Are there software implementations of GLSL which we can reuse? I imagine that would seriously affect how much effort it would be to have a software implementation of custom filters. Cheers, Nick On Wednesday, May 1, 2013 6:41:38 PM UTC+12, Andreas Gal wrote: > 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
