On Wednesday, May 1, 2013 7:22:47 PM UTC+12, Andreas Gal wrote: > On May 1, 2013, at 12:14 AM, Nicholas Cameron <nick.r.came...@gmail.com> > wrote: > > > > > 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, > > > > Minus support for 3D transforms which boil down to 3 lines of shader math, > why do you think that Moz2D would have to become a 3D graphics library? > Right now, Moz2D doesn't have the concept of shaders to add those lines to. It barely has support for 4x4 matrices, and I presume if we wanted to add support for composition and 3D transforms in the same way layers does, then we would need to support that throughout the API and the implementations. I think that we could not always rely on shaders so we would need software support too. None of this is insurmountable, or even that complex, but I think there is a lot of it. Supporting things like tiling and gralloc sounds like something we could do, but that Moz2D might not be the best place for.
If we are lucky, we can just add a Composite method to the DrawTarget API, but I suspect we would end up merging a lot of the Compositor API along with it, and that would turn into a pretty serious undertaking. > > > > 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. > > > > My understanding is that we are betting on SkiaGL and D2D as the content > acceleration paths of the future. If that is true, why do we think that those > paths are ok for content rendering, but not for compositing? > I didn't know we were betting on SkiaGL yet, I thought we were still waiting to see if it delivers the results we are expecting. In any case, drawing content and compositing are very different things - as an example, for canvas we found Skia to be faster at the former and Cairo faster at the latter (or blitting operations similar to compositing). Just because SkiaGL and D2D are the best way to draw content, doesn't mean they are the best way to composite. I'm not sure whether we are talking about just SkiaGL/D2D or SkiaGL and GL/D2D and D3D, I'm not even sure if the former is a flexible enough option for us. > > > > 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. > > > > I absolutely don't think its worth refactoring like this for filters. I am > asking the question whether our gfx stack should be architected like this in > general. > Ah, OK. I thought filters were still the motivation, sorry. Perhaps we should start a new topic about the graphics backends in general? Cheers, Nick > > > > > > > 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. > > > > Thats really the conversation I would like to have actually. Filters are the > occasion, but not the sole purpose. > > > > Andreas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
