Bug 86666

TransformationMatrix rotate3d() (both overloaded versions) seem to use unnecessary indirect computations to initialize the rotation matrices. Specifically, instead of using cos(theta) and sin(theta) directly, this code computes cos(theta/2), sin(theta/2) and sin^2 (theta/2), and then uses trig identities to compute the same traditional rotation matrices. I did some quick and dirty fprintf experiment, which suggested that using traditional sin/cos we can gain 1-2 bits of precision in some cases, particularly for the sin^2 term, where the squaring compounds the error. Perhaps this code should be simplified to use just sin/cos to create the canonical rotation matrices. Two possible caveats of simplifying this code: - perhaps there was a good reason to compute theta/2 and then use those trig identities? I cannot think of why. - There is a chance this will require rebaselining a vast number of pixel tests, and I would need some suggestions how to minimize the risk and pain of breaking all pixel tests for a short while. Dean and Chris, do either of you feel that this code should stay the way it is now? Doing this is not high priority, but if you want it done, I think its a reasonable safe change to make except for the rebaselining. Thanks in advance.