At first SVGMatrix and the complete SVG code itself is not using TransformationMatrix. We had bigger performance problems and the memory amount raised up by 6-10%. Thats why we decided to turn back to AffineTransform.
Because of the platform dependencies of TransformationMatrix. I noted that replacing AffineTransform, that was platform dependent at that time, by TransformationMatrix, which wasn't, may cause performance losses. At this time it was not clear that we would use 3D all over the place. I was told that the great benefit of a independent implementation is, that we get same results across platforms (a bigger problem that we saw on DRT and which caused a lot of platform dependent results). Is this argument not valid or important anymore? Cheers Dirk > > The current reworking of the TransformationMatrix class and friends > (https://bugs.webkit.org/show_bug.cgi?id=48031) got me thinking about the > future of this class. I've chit chatted about this with various people, but > nothing serious has been done yet. > > As WebKit and "HTML5" get more 3D functionality (CSS Transforms now, WebGL > later) a 4x4 matrix class becomes more important. There has even been talk of > adding 3D transforms to SVG. Today, the workhorse 3D matrix class is > TransformationMatrix. This is used by SVGMatrix and CSSMatrix and internally > in several places. The above bug is making the functions in > TransformationMatrix more rational and that is a good first step. But we need > to architect the most efficient class hierarchy in this area as possible. > > For instance, today you can use CSSMatrix in WebGL. But it has an inordinate > amount of overhead because the class is immutable. So every call that is made > must construct a new CSSMatrix. This not only adds call overhead, but in the > GC workload as well. I feel that making a mutable 4x4 matrix available is > very important. This could be done with a base Matrix class, available to > JavaScript, which would have mutable calls. Then SVGMatrix and CSSMatrix > could derive from this with their own APIs. > > Internally, I think we should eventually restructure TransformationMatrix to > have mutable fast-path operations. Today, for instance, operator*= calls into > the operator* class, so there's always an extra matrix copy. That should be > changed and we should similarly have mutable versions of all the calls > (translate, rotate, etc.) on the fast path. > > We should also restructure TransformationMatrix to allow for platform > specific versions of the calls. For instance, PLATFORM(CA) has access to > CATransform3D, which has accelerated versions of its API where possible. I'm > sure QMatrix, SkMatrix and others might also be able to be used for similar > performance gains. > > I've opened a couple of bugs for this: > > https://bugs.webkit.org/show_bug.cgi?id=52488 > https://bugs.webkit.org/show_bug.cgi?id=52490 > > Please feel free to comment here or there… > > ----- > ~Chris > cmar...@apple.com > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
