Index: src/gpu/batches/GrPLSPathRenderer.h |
diff --git a/src/gpu/batches/GrPLSPathRenderer.h b/src/gpu/batches/GrPLSPathRenderer.h |
index d701f62a91146b1f23b33e820849402a2321f00f..39f21ba68c1b0c95bb3b1dba7f0d0f92f95ba328 100644 |
--- a/src/gpu/batches/GrPLSPathRenderer.h |
+++ b/src/gpu/batches/GrPLSPathRenderer.h |
@@ -1,4 +1,3 @@ |
- |
/* |
* Copyright 2012 Google Inc. |
* |
@@ -13,26 +12,26 @@ |
/* |
* Renders arbitrary antialiased paths using pixel local storage as a scratch buffer. The overall |
- * technique is very similar to the approach presented in "Resolution independent rendering of |
+ * technique is very similar to the approach presented in "Resolution independent rendering of |
* deformable vector objects using graphics hardware" by Kokojima et al. |
* We first render the straight-line portions of the path (essentially pretending as if all segments |
- * were kLine_Verb) as a triangle fan, using a fragment shader which updates the winding counts |
- * appropriately. We then render the curved portions of the path using a Loop-Blinn shader which |
+ * were kLine_Verb) as a triangle fan, using a fragment shader which updates the winding counts |
+ * appropriately. We then render the curved portions of the path using a Loop-Blinn shader which |
* calculates which portion of the triangle is covered by the quad (conics and cubics are split down |
- * to quads). Where we diverge from Kokojima is that, instead of rendering into the stencil buffer |
+ * to quads). Where we diverge from Kokojima is that, instead of rendering into the stencil buffer |
* and using built-in MSAA to handle straight-line antialiasing, we use the pixel local storage area |
- * and calculate the MSAA ourselves in the fragment shader. Essentially, we manually evaluate the |
+ * and calculate the MSAA ourselves in the fragment shader. Essentially, we manually evaluate the |
* coverage of each pixel four times, storing four winding counts into the pixel local storage area, |
* and compute the final coverage based on those winding counts. |
* |
- * Our approach is complicated by the need to perform antialiasing on straight edges as well, |
- * without relying on hardware MSAA. We instead bloat the triangles to ensure complete coverage, |
- * pass the original (un-bloated) vertices in to the fragment shader, and then have the fragment |
- * shader use these vertices to evaluate whether a given sample is located within the triangle or |
+ * Our approach is complicated by the need to perform antialiasing on straight edges as well, |
+ * without relying on hardware MSAA. We instead bloat the triangles to ensure complete coverage, |
+ * pass the original (un-bloated) vertices in to the fragment shader, and then have the fragment |
+ * shader use these vertices to evaluate whether a given sample is located within the triangle or |
* not. This gives us MSAA4 edges on triangles which line up nicely with no seams. We similarly face |
- * problems on the back (flat) edges of quads, where we have to ensure that the back edge is |
- * antialiased in the same way. Similar to the triangle case, we pass in the two (unbloated) |
+ * problems on the back (flat) edges of quads, where we have to ensure that the back edge is |
+ * antialiased in the same way. Similar to the triangle case, we pass in the two (unbloated) |
* vertices defining the back edge of the quad and the fragment shader uses these vertex coordinates |
* to discard samples falling on the other side of the quad's back edge. |
*/ |