Fix for bug where composited rotate3d should SLERP

cc/animation/transform_operations.cc

Index: cc/animation/transform_operations.cc
diff --git a/cc/animation/transform_operations.cc b/cc/animation/transform_operations.cc
index fb1c17d517598e3c23af197d72996558d02e70a9..6631a2a980b0eefa426ed4582ec68a231156fd8c 100644
--- a/cc/animation/transform_operations.cc
+++ b/cc/animation/transform_operations.cc
@@ -277,10 +277,9 @@ bool TransformOperations::BlendInternal(const TransformOperations& from,
     for (size_t i = 0; i < num_operations; ++i) {
       gfx::Transform blended;
       if (!TransformOperation::BlendTransformOperations(
-          from_identity ? 0 : &from.operations_[i],
-          to_identity ? 0 : &operations_[i],
-          progress,
-          &blended))
+              from.operations_.size() <= i ? 0 : &from.operations_[i],
+              operations_.size() <= i ? 0 : &operations_[i], progress,

[ajuma, 2015/06/24 14:47:45]

Please add a test for this change too.

[soonm, 2015/06/26 07:48:38]

The new tests I've added for the corrected shareSameAxis checks depend on this
behavior.

So they will correctly fail if this part is reverted. The identity transform
tests currently in the
transform_operations_unittest does test this code part.

I think the original code is an optimization on figuring out if the whole list
of transform operations
are already identity, if so, then just use a 0. However, this is bad for
rotations because rotate axis
does not get encoded into the matrix representations when the rotation angle is
0 deg. (ie no rotation)

so isIdentity will return true...which is sort of correct.

In this change, I allow the for-loop to use those functions even though they
could possibly be identity.
I suspect only a performance test with many transforms will be able to pick it
up.

[ajuma, 2015/06/26 13:13:31]

Ah, of course, thanks for the explanation!

+              &blended))
           return false;
       result->PreconcatTransform(blended);
     }