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

Side by Side Diff: src/gpu/batches/GrPLSPathRenderer.h

Issue 1626553002: Revert of added support for PLS path rendering (Closed) Base URL: https://skia.googlesource.com/skia.git@master
Patch Set: 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 unified diff | Download patch
« no previous file with comments | « src/gpu/batches/GrAtlasTextBatch.cpp ('k') | src/gpu/batches/GrPLSPathRenderer.cpp » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1
2 /*
3 * Copyright 2012 Google Inc.
4 *
5 * Use of this source code is governed by a BSD-style license that can be
6 * found in the LICENSE file.
7 */
8
9 #ifndef GrPLSPathRenderer_DEFINED
10 #define GrPLSPathRenderer_DEFINED
11
12 #include "GrPathRenderer.h"
13
14 /*
15 * Renders arbitrary antialiased paths using pixel local storage as a scratch bu ffer. The overall
16 * technique is very similar to the approach presented in "Resolution independen t rendering of
17 * deformable vector objects using graphics hardware" by Kokojima et al.
18
19 * We first render the straight-line portions of the path (essentially pretendin g as if all segments
20 * were kLine_Verb) as a triangle fan, using a fragment shader which updates the winding counts
21 * appropriately. We then render the curved portions of the path using a Loop-Bl inn shader which
22 * calculates which portion of the triangle is covered by the quad (conics and c ubics are split down
23 * to quads). Where we diverge from Kokojima is that, instead of rendering into the stencil buffer
24 * and using built-in MSAA to handle straight-line antialiasing, we use the pixe l local storage area
25 * and calculate the MSAA ourselves in the fragment shader. Essentially, we manu ally evaluate the
26 * coverage of each pixel four times, storing four winding counts into the pixel local storage area,
27 * and compute the final coverage based on those winding counts.
28 *
29 * Our approach is complicated by the need to perform antialiasing on straight e dges as well,
30 * without relying on hardware MSAA. We instead bloat the triangles to ensure co mplete coverage,
31 * pass the original (un-bloated) vertices in to the fragment shader, and then h ave the fragment
32 * shader use these vertices to evaluate whether a given sample is located withi n the triangle or
33 * not. This gives us MSAA4 edges on triangles which line up nicely with no seam s. We similarly face
34 * problems on the back (flat) edges of quads, where we have to ensure that the back edge is
35 * antialiased in the same way. Similar to the triangle case, we pass in the two (unbloated)
36 * vertices defining the back edge of the quad and the fragment shader uses thes e vertex coordinates
37 * to discard samples falling on the other side of the quad's back edge.
38 */
39 class GrPLSPathRenderer : public GrPathRenderer {
40 public:
41 GrPLSPathRenderer();
42
43 bool onCanDrawPath(const CanDrawPathArgs& args) const override;
44
45 protected:
46 bool onDrawPath(const DrawPathArgs& args) override;
47 };
48
49 #endif
OLDNEW
« no previous file with comments | « src/gpu/batches/GrAtlasTextBatch.cpp ('k') | src/gpu/batches/GrPLSPathRenderer.cpp » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698