cleanup

svn-id: r36289

1 files changed, 6 insertions, 8 deletions

diff --git a/graphics/scaler.cpp b/graphics/scaler.cpp
index adfcda128d..7eeb9a07d9 100644
--- a/graphics/scaler.cpp
+++ b/graphics/scaler.cpp
@@ -73,19 +73,17 @@ uint32 hqx_redBlueMask = 0;
 uint32 hqx_green_redBlue_Mask = 0;
 
 // FIXME/TODO: The RGBtoYUV table sucks up 256 KB. This is bad.
-// In addition we never free them...
+// In addition we never free it...
 //
 // Note: a memory lookup table is *not* necessarily faster than computing
-// these things on the fly, because of its size. Both tables together, plus
-// the code, plus the input/output GFX data, won't fit in the cache on many
+// these things on the fly, because of its size. The table together with
+// the code, plus the input/output GFX data, may not fit in the cache on some
 // systems, so main memory has to be accessed, which is about the worst thing
 // that can happen to code which tries to be fast...
 //
-// So we should think about ways to get these smaller / removed. Maybe we can
-// use the same technique which is employed by our MPEG code to reduce the
-// size of the lookup tables at the cost of some additional computations? That
-// might actually result in a speedup, too, if done right (and the code code
-// might actually be suitable for AltiVec/MMX/SSE speedup).
+// So we should think about ways to get this smaller / removed. Maybe we can
+// use the same technique employed by our MPEG code to reduce the size of the
+// lookup table at the cost of some additional computations?
 //
 // Of course, the above is largely a conjecture, and the actual speed
 // differences are likely to vary a lot between different architectures and