Use LCD text if the transform IsAlmostIdentityAndIntegerTranslation

cc/layer_tree_host_common.cc

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/layer_tree_host_common.h"
 
 #include <algorithm>
 
 #include "base/debug/trace_event.h"
 #include "cc/heads_up_display_layer_impl.h"
@@ skipping 713 matching lines @@
     layerDrawProperties.screen_space_transform = fullHierarchyMatrix;
     if (!layer->preserves3D())
         layerDrawProperties.screen_space_transform.FlattenTo2d();
     layerDrawProperties.screen_space_transform.PreconcatTransform(layerDrawProperties.target_space_transform);
 
     // Adjusting text AA method during animation may cause repaints, which in-turn causes jank.
     bool adjustTextAA = !animatingOpacityToScreen && !animatingTransformToScreen;
     // To avoid color fringing, LCD text should only be used on opaque layers with just integral translation.
     bool layerCanUseLCDText = subtreeCanUseLCDText &&
                               (accumulatedDrawOpacity == 1.0) &&
-                              layerDrawProperties.target_space_transform.IsIdentityOrIntegerTranslation();
+                              layerDrawProperties.target_space_transform.IsAlmostIdentityOrIntegerTranslation();

[alokp, 2013/03/08 19:40:06]

If you make a decision based on rounded transform, but use the actual transform
to do the drawing, I am not sure if the pixels will line up as expected. I also
do not know how to compute the epsilon that lets you do this.

I will be more comfortable if we were also modifying the target-space-transform,
but I am sure it will cause other problems.

[Xianzhu, 2013/03/08 23:36:56]

Do you have experience about how much pixel displacement would cause color
fringing? For example, would 1/1000 displacement cause it? 1/1000 is the
displacement of the bottom-right-most pixel when we use 1e-6 epsilon for a
1000x1000 screen.

About blurriness, based on my tests, >1/10 pixel displacement will cause visible
blurriness. Given a 1000x1000 screen, a scale error >1e-4 (1/10 * 1/1000) will
cause the bottom-right-most pixel to get a displacement >1/10 pixels.
Patch Set 1 modifies target_space_transform, which got also many concerns.

 
     gfx::RectF contentRect(gfx::PointF(), layer->contentBounds());
 
     // fullHierarchyMatrix is the matrix that transforms objects between screen space (except projection matrix) and the most recent RenderSurfaceImpl's space.
     // nextHierarchyMatrix will only change if this layer uses a new RenderSurfaceImpl, otherwise remains the same.
     gfx::Transform nextHierarchyMatrix = fullHierarchyMatrix;
     gfx::Transform sublayerMatrix;
 
     gfx::Vector2dF renderSurfaceSublayerScale = MathUtil::computeTransform2dScaleComponents(combinedTransform, deviceScaleFactor * pageScaleFactor);
 
@@ skipping 469 matching lines @@
 
   // At this point, we think the point does hit the touch event handler region on the layer, but we need to walk up
   // the parents to ensure that the layer was not clipped in such a way that the
   // hit point actually should not hit the layer.
   if (pointIsClippedBySurfaceOrClipRect(screenSpacePoint, layerImpl))
      return false;
 
   return true;
 }
 }  // namespace cc