[webkit-dev] The future of TransformationMatrix

[Dirk Schulze]

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
> cmarrin at apple.com
> 
> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110115/0f58063f/attachment.html>