[webkit-dev] The future of TransformationMatrix

Chris Marrin cmarrin at apple.com
Fri Jan 14 15:49:30 PST 2011

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:


Please feel free to comment here or there…

cmarrin at apple.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110114/2df00b20/attachment.html>

More information about the webkit-dev mailing list