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? > 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? > 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. > > 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
