Update Alligned Rect Shader to match geometry version

src/gpu/GrAARectRenderer.cpp

Index: src/gpu/GrAARectRenderer.cpp
diff --git a/src/gpu/GrAARectRenderer.cpp b/src/gpu/GrAARectRenderer.cpp
index f28d91456308143206a0f77310df60cd8a24f263..bbaf18c79f659fbdb9e0c09750844c2fd46d8f79 100644
--- a/src/gpu/GrAARectRenderer.cpp
+++ b/src/gpu/GrAARectRenderer.cpp
@@ -61,21 +61,22 @@ public:
 
             // TODO: compute these scale factors in the VS
             // These scale factors adjust the coverage for < 1 pixel wide/high rects
-            builder->fsCodeAppendf("\tfloat wScale = max(1.0, 2.0/(0.5+%s.z));\n",
-                                   fsRectName);
-            builder->fsCodeAppendf("\tfloat hScale = max(1.0, 2.0/(0.5+%s.w));\n",
-                                   fsRectName);
+            builder->fsCodeAppendf("\tfloat insetW = min(1.0, %s.z) - 0.5;\n", fsRectName);
+            builder->fsCodeAppendf("\tfloat insetH = min(1.0, %s.w) - 0.5;\n", fsRectName);
+            builder->fsCodeAppend("\tfloat outset = 0.5;\n");

[robertphillips, 2013/06/13 17:45:52]

// For rects > 1 pixel wide and tall the span*s are noops (i.e., 1.0). For rects
< 1 pixel wide or tall they serve to normalize the < 1 ramp to a 0 .. 1 range.

[egdaniel, 2013/06/13 19:17:46]

I'm sorry I'm confused, are you simply stating what the code does, should be
doing, or suggesting I add that as a comment since I do believe the code does
what is described

[robertphillips, 2013/06/13 19:55:24]

Add a comment

+            builder->fsCodeAppend("\tfloat spanW = insetW + outset;\n");
+            builder->fsCodeAppend("\tfloat spanH = insetH + outset;\n");
+            builder->fsCodeAppend("\tfloat scaleW = min(1.0, 2*insetW/spanW);\n");
+            builder->fsCodeAppend("\tfloat scaleH = min(1.0, 2*insetH/spanH);\n");
 
             // Compute the coverage for the rect's width

[robertphillips, 2013/06/13 17:45:52]

Why not put the scales inside the clamps?

[egdaniel, 2013/06/13 19:17:46]

What would this save us or improve? To keep the algorithm the same, if I put the
scales inside the clamp then I would also need to set the clamps max bound to be
equal to the scale. 

My general idea of what the scale is doing (which I believe is how geometry is
also implemented) is that the ramp at the outset is zero and the ramp at the
inset is "scale". And then anything inside of the inset also set to scale. Is
this correct?

[robertphillips, 2013/06/13 19:55:24]

So, was the inclusion of the scale inside the clamp in the prior version
incorrect?

[egdaniel, 2013/06/13 20:04:03]

So in the previous version, the scale worked slightly differently. In that
version the scale was always >= 1. In essence the old scale was performing an
equivalent function as the divide by span that I have which is to transform a
scale of "0 to x" where x is < 1 to a scale of "0 to 1". The new scale I've
added is there as more of a may to cap the maximum coverage.

-            builder->fsCodeAppendf("\tfloat coverage = clamp(wScale*(%s.z-abs(%s.x)), 0.0, 1.0);\n",
-                                   fsRectName,
-                                   fsRectName);
-
+            builder->fsCodeAppendf(
+                "\tfloat coverage = scaleW*clamp((%s.z-abs(%s.x))/spanW, 0.0, 1.0);\n", fsRectName,
+                fsRectName);
             // Compute the coverage for the rect's height and merge with the width
             builder->fsCodeAppendf(
-                    "\tcoverage = min(coverage, clamp(hScale*(%s.w-abs(%s.y)), 0.0, 1.0));\n",
-                    fsRectName,
-                    fsRectName);
+                "\tcoverage = coverage*scaleH*clamp((%s.w-abs(%s.y))/spanH, 0.0, 1.0);\n",
+                fsRectName, fsRectName);
 
             SkString modulate;
             GrGLSLModulatef<4>(&modulate, inputColor, "coverage");