- From: Chris Marrin <cmarrin@apple.com>
- Date: Wed, 18 Jan 2012 07:29:47 -0800
- To: Johannes Behr <johannes.behr@igd.fraunhofer.de>
- Cc: Dean Jackson <dino@apple.com>, public-fx@w3.org, igor.oliveira@openbossa.org, public-d3d mlist <public-declarative3d@w3.org>, Timm Drevensek <timm.drevensek@igd.fraunhofer.de>
- Message-id: <BCE8C1CD-4A8D-4942-A603-EF386600ABF7@apple.com>
On Jan 17, 2012, at 10:18 AM, Johannes Behr wrote: > >> On 14/01/2012, at 2:49 AM, Johannes Behr wrote: >> >>> Before going into more details: Was there a good reason for just a single matrix interface and not a minimalistic but useful set of base types (e.g. Vec3, Vec4, Matrix4x4 or even Quaternion) which would be really helpful for various math related operations (e.g composition/decomposition)? We (especially Timm) thought about something similar for the dec3d group: http://www.w3.org/community/declarative3d/wiki/Base_Types >> >> I considered this. My main concern is fear of polluting the global JS namespace with generic classes that might be better developed by the official ECMAScript committee. Adding interfaces to the DOM when they are clearly related to the Web and Web documents is ok, but I think we need to show caution adding 6 interfaces that have broader use. I believe this is why the WebGL group discussed the *Array classes with ECMA. >> >> I would prefer to have the base types as you suggest, but I'm not sure how to proceed. Maybe I'm being overly cautious. > > There are ways to deal with the polluting problem and I believe we should really wisely consider the correct representation. > We really have to look at the use cases but there is real risk that we run into performance issues if we consider not the right set of base types and interfaces. > There is already a essential fragmentation between different math/matrix libraries used in the various webgl-related projects. > Code reuse or the mixture of interaction, physics simulation and rendering components in a single application is therefore not easy to achieve. > This could be a real opportunity for a single adequate, efficient and minimal set of base-types which could be used for SVG, CSS, Dec3D and WebGL related interfaces. > Just image a physics simulation package which could be use with SVG, CSS, Dec3D and WebGL. I don't think there will ever be a way to produce a library of linear algebra classes that will be "adequate" for all purposes. I don't see the plethora of matrix libraries as a source of fragmentation, but as a reality of web development today. The more functional we make a set of linear algebra classes the more change there is to miss the mark for a large number of use cases. Therefore I think we should focus on the absolutely minimum set of functionality needed to solve the majority of the performance problems that come up with these classes. I think Dean's current design is very close to that. It may be desirable to have a 3D Vector class with dot(), cross() and other common functions, but is it necessary for maximum performance? Are these functions going to be in the inner loop enough that they become a significant performance bottleneck? I'd say probably not for the majority of use cases. I understand your desire to have a complete and elegant set of classes to support 3D functionality. But the real goal of this exercise is to produce a common and efficient matrix class for use in WebGL and other 3D use cases. ----- ~Chris cmarrin@apple.com
Received on Wednesday, 18 January 2012 15:30:34 UTC