Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(259)

Unified Diff: src/gpu/batches/GrPLSPathRenderer.h

Issue 1541903002: added support for PLS path rendering (Closed) Base URL: https://skia.googlesource.com/skia.git@master
Patch Set: fix for ASAN failure Created 4 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « src/gpu/batches/GrNonAAStrokeRectBatch.cpp ('k') | src/gpu/batches/GrPLSPathRenderer.cpp » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: src/gpu/batches/GrPLSPathRenderer.h
diff --git a/src/gpu/batches/GrPLSPathRenderer.h b/src/gpu/batches/GrPLSPathRenderer.h
new file mode 100644
index 0000000000000000000000000000000000000000..d701f62a91146b1f23b33e820849402a2321f00f
--- /dev/null
+++ b/src/gpu/batches/GrPLSPathRenderer.h
@@ -0,0 +1,49 @@
+
+/*
+ * Copyright 2012 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef GrPLSPathRenderer_DEFINED
+#define GrPLSPathRenderer_DEFINED
+
+#include "GrPathRenderer.h"
+
+/*
+ * 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
+ * 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
+ * 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
+ * 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
+ * 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
+ * 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)
+ * 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.
+ */
+class GrPLSPathRenderer : public GrPathRenderer {
+public:
+ GrPLSPathRenderer();
+
+ bool onCanDrawPath(const CanDrawPathArgs& args) const override;
+
+protected:
+ bool onDrawPath(const DrawPathArgs& args) override;
+};
+
+#endif
« no previous file with comments | « src/gpu/batches/GrNonAAStrokeRectBatch.cpp ('k') | src/gpu/batches/GrPLSPathRenderer.cpp » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698