Implementation of principal-component color reduction.

ui/gfx/vector3d_f.cc

Index: ui/gfx/vector3d_f.cc
diff --git a/ui/gfx/vector3d_f.cc b/ui/gfx/vector3d_f.cc
index 02f0378832491261cca41986fefe7abedee86502..a6fd6116d47d2ff3509942c85fe90221905fac1a 100644
--- a/ui/gfx/vector3d_f.cc
+++ b/ui/gfx/vector3d_f.cc
@@ -72,8 +72,8 @@ void Vector3dF::Cross(const Vector3dF& other) {
   z_ = z;
 }
 
-float DotProduct(const Vector3dF& lhs, const Vector3dF& rhs) {
-  return lhs.x() * rhs.x() + lhs.y() * rhs.y() + lhs.z() * rhs.z();
+float DotProduct(const Vector3dF& lhs, float x, float y, float z) {

[Alexei Svitkine (slow), 2013/02/21 16:49:59]

Instead of this, can you make a Vector3dF constructor that takes three floats?
Then you can do DotProduct(a, Vector3dF(x, y, z)).

[motek., 2013/02/21 18:38:43]

Well, I would need to call this, in a typical image process, some 10M times. I
realize the compiler would make a good job of it, but still it will just scream
*wrong*. 
If you particularly dislike this change, I'd rather implement multiplication
in-place. 

[reed1, 2013/02/21 19:36:37]

+1 -- the inner loop is no place to unnecessarily rely on an optional compiler
optimization.

[Alexei Svitkine (slow), 2013/02/21 19:54:31]

I'd be surprised if the compilers we use don't produce equivalent code if the
Vector3dF(x,y,z) ctor is put in the header and marked inline.

I'd like to see evidence to the contrary here, in which case we can add a
comment explaining why it's done this way. If committed this way without any
comment, then it's more than likely someone will end up refactoring it to the
form I suggest if the rationale for doing it this way is not in the code.

[reed1, 2013/02/21 19:57:09]

Possibly, or the reverse, where we would need a comment assuring the reader that
the optimization always occurs (w/ some test to back that up.)

I think here may be a case where we defer to the aesthetics of the author.

+  return lhs.x() * x + lhs.y() * y + lhs.z() * z;
 }
 
 Vector3dF ScaleVector3d(const Vector3dF& v,