gfx/skia/trunk/src/gpu/GrPathUtils.h

Wed, 31 Dec 2014 06:09:35 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Wed, 31 Dec 2014 06:09:35 +0100
changeset 0
6474c204b198
permissions
-rw-r--r--

Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.

michael@0 1 /*
michael@0 2 * Copyright 2011 Google Inc.
michael@0 3 *
michael@0 4 * Use of this source code is governed by a BSD-style license that can be
michael@0 5 * found in the LICENSE file.
michael@0 6 */
michael@0 7
michael@0 8 #ifndef GrPathUtils_DEFINED
michael@0 9 #define GrPathUtils_DEFINED
michael@0 10
michael@0 11 #include "GrPoint.h"
michael@0 12 #include "SkRect.h"
michael@0 13 #include "SkPath.h"
michael@0 14 #include "SkTArray.h"
michael@0 15
michael@0 16 class SkMatrix;
michael@0 17
michael@0 18 /**
michael@0 19 * Utilities for evaluating paths.
michael@0 20 */
michael@0 21 namespace GrPathUtils {
michael@0 22 SkScalar scaleToleranceToSrc(SkScalar devTol,
michael@0 23 const SkMatrix& viewM,
michael@0 24 const SkRect& pathBounds);
michael@0 25
michael@0 26 /// Since we divide by tol if we're computing exact worst-case bounds,
michael@0 27 /// very small tolerances will be increased to gMinCurveTol.
michael@0 28 int worstCasePointCount(const SkPath&,
michael@0 29 int* subpaths,
michael@0 30 SkScalar tol);
michael@0 31
michael@0 32 /// Since we divide by tol if we're computing exact worst-case bounds,
michael@0 33 /// very small tolerances will be increased to gMinCurveTol.
michael@0 34 uint32_t quadraticPointCount(const GrPoint points[], SkScalar tol);
michael@0 35
michael@0 36 uint32_t generateQuadraticPoints(const GrPoint& p0,
michael@0 37 const GrPoint& p1,
michael@0 38 const GrPoint& p2,
michael@0 39 SkScalar tolSqd,
michael@0 40 GrPoint** points,
michael@0 41 uint32_t pointsLeft);
michael@0 42
michael@0 43 /// Since we divide by tol if we're computing exact worst-case bounds,
michael@0 44 /// very small tolerances will be increased to gMinCurveTol.
michael@0 45 uint32_t cubicPointCount(const GrPoint points[], SkScalar tol);
michael@0 46
michael@0 47 uint32_t generateCubicPoints(const GrPoint& p0,
michael@0 48 const GrPoint& p1,
michael@0 49 const GrPoint& p2,
michael@0 50 const GrPoint& p3,
michael@0 51 SkScalar tolSqd,
michael@0 52 GrPoint** points,
michael@0 53 uint32_t pointsLeft);
michael@0 54
michael@0 55 // A 2x3 matrix that goes from the 2d space coordinates to UV space where
michael@0 56 // u^2-v = 0 specifies the quad. The matrix is determined by the control
michael@0 57 // points of the quadratic.
michael@0 58 class QuadUVMatrix {
michael@0 59 public:
michael@0 60 QuadUVMatrix() {};
michael@0 61 // Initialize the matrix from the control pts
michael@0 62 QuadUVMatrix(const GrPoint controlPts[3]) { this->set(controlPts); }
michael@0 63 void set(const GrPoint controlPts[3]);
michael@0 64
michael@0 65 /**
michael@0 66 * Applies the matrix to vertex positions to compute UV coords. This
michael@0 67 * has been templated so that the compiler can easliy unroll the loop
michael@0 68 * and reorder to avoid stalling for loads. The assumption is that a
michael@0 69 * path renderer will have a small fixed number of vertices that it
michael@0 70 * uploads for each quad.
michael@0 71 *
michael@0 72 * N is the number of vertices.
michael@0 73 * STRIDE is the size of each vertex.
michael@0 74 * UV_OFFSET is the offset of the UV values within each vertex.
michael@0 75 * vertices is a pointer to the first vertex.
michael@0 76 */
michael@0 77 template <int N, size_t STRIDE, size_t UV_OFFSET>
michael@0 78 void apply(const void* vertices) {
michael@0 79 intptr_t xyPtr = reinterpret_cast<intptr_t>(vertices);
michael@0 80 intptr_t uvPtr = reinterpret_cast<intptr_t>(vertices) + UV_OFFSET;
michael@0 81 float sx = fM[0];
michael@0 82 float kx = fM[1];
michael@0 83 float tx = fM[2];
michael@0 84 float ky = fM[3];
michael@0 85 float sy = fM[4];
michael@0 86 float ty = fM[5];
michael@0 87 for (int i = 0; i < N; ++i) {
michael@0 88 const GrPoint* xy = reinterpret_cast<const GrPoint*>(xyPtr);
michael@0 89 GrPoint* uv = reinterpret_cast<GrPoint*>(uvPtr);
michael@0 90 uv->fX = sx * xy->fX + kx * xy->fY + tx;
michael@0 91 uv->fY = ky * xy->fX + sy * xy->fY + ty;
michael@0 92 xyPtr += STRIDE;
michael@0 93 uvPtr += STRIDE;
michael@0 94 }
michael@0 95 }
michael@0 96 private:
michael@0 97 float fM[6];
michael@0 98 };
michael@0 99
michael@0 100 // Input is 3 control points and a weight for a bezier conic. Calculates the
michael@0 101 // three linear functionals (K,L,M) that represent the implicit equation of the
michael@0 102 // conic, K^2 - LM.
michael@0 103 //
michael@0 104 // Output:
michael@0 105 // K = (klm[0], klm[1], klm[2])
michael@0 106 // L = (klm[3], klm[4], klm[5])
michael@0 107 // M = (klm[6], klm[7], klm[8])
michael@0 108 void getConicKLM(const SkPoint p[3], const SkScalar weight, SkScalar klm[9]);
michael@0 109
michael@0 110 // Converts a cubic into a sequence of quads. If working in device space
michael@0 111 // use tolScale = 1, otherwise set based on stretchiness of the matrix. The
michael@0 112 // result is sets of 3 points in quads (TODO: share endpoints in returned
michael@0 113 // array)
michael@0 114 // When we approximate a cubic {a,b,c,d} with a quadratic we may have to
michael@0 115 // ensure that the new control point lies between the lines ab and cd. The
michael@0 116 // convex path renderer requires this. It starts with a path where all the
michael@0 117 // control points taken together form a convex polygon. It relies on this
michael@0 118 // property and the quadratic approximation of cubics step cannot alter it.
michael@0 119 // Setting constrainWithinTangents to true enforces this property. When this
michael@0 120 // is true the cubic must be simple and dir must specify the orientation of
michael@0 121 // the cubic. Otherwise, dir is ignored.
michael@0 122 void convertCubicToQuads(const GrPoint p[4],
michael@0 123 SkScalar tolScale,
michael@0 124 bool constrainWithinTangents,
michael@0 125 SkPath::Direction dir,
michael@0 126 SkTArray<SkPoint, true>* quads);
michael@0 127
michael@0 128 // Chops the cubic bezier passed in by src, at the double point (intersection point)
michael@0 129 // if the curve is a cubic loop. If it is a loop, there will be two parametric values for
michael@0 130 // the double point: ls and ms. We chop the cubic at these values if they are between 0 and 1.
michael@0 131 // Return value:
michael@0 132 // Value of 3: ls and ms are both between (0,1), and dst will contain the three cubics,
michael@0 133 // dst[0..3], dst[3..6], and dst[6..9] if dst is not NULL
michael@0 134 // Value of 2: Only one of ls and ms are between (0,1), and dst will contain the two cubics,
michael@0 135 // dst[0..3] and dst[3..6] if dst is not NULL
michael@0 136 // Value of 1: Neither ls or ms are between (0,1), and dst will contain the one original cubic,
michael@0 137 // dst[0..3] if dst is not NULL
michael@0 138 //
michael@0 139 // Optional KLM Calculation:
michael@0 140 // The function can also return the KLM linear functionals for the chopped cubic implicit form
michael@0 141 // of K^3 - LM.
michael@0 142 // It will calculate a single set of KLM values that can be shared by all sub cubics, except
michael@0 143 // for the subsection that is "the loop" the K and L values need to be negated.
michael@0 144 // Output:
michael@0 145 // klm: Holds the values for the linear functionals as:
michael@0 146 // K = (klm[0], klm[1], klm[2])
michael@0 147 // L = (klm[3], klm[4], klm[5])
michael@0 148 // M = (klm[6], klm[7], klm[8])
michael@0 149 // klm_rev: These values are flags for the corresponding sub cubic saying whether or not
michael@0 150 // the K and L values need to be flipped. A value of -1.f means flip K and L and
michael@0 151 // a value of 1.f means do nothing.
michael@0 152 // *****DO NOT FLIP M, JUST K AND L*****
michael@0 153 //
michael@0 154 // Notice that the klm lines are calculated in the same space as the input control points.
michael@0 155 // If you transform the points the lines will also need to be transformed. This can be done
michael@0 156 // by mapping the lines with the inverse-transpose of the matrix used to map the points.
michael@0 157 int chopCubicAtLoopIntersection(const SkPoint src[4], SkPoint dst[10] = NULL,
michael@0 158 SkScalar klm[9] = NULL, SkScalar klm_rev[3] = NULL);
michael@0 159
michael@0 160 // Input is p which holds the 4 control points of a non-rational cubic Bezier curve.
michael@0 161 // Output is the coefficients of the three linear functionals K, L, & M which
michael@0 162 // represent the implicit form of the cubic as f(x,y,w) = K^3 - LM. The w term
michael@0 163 // will always be 1. The output is stored in the array klm, where the values are:
michael@0 164 // K = (klm[0], klm[1], klm[2])
michael@0 165 // L = (klm[3], klm[4], klm[5])
michael@0 166 // M = (klm[6], klm[7], klm[8])
michael@0 167 //
michael@0 168 // Notice that the klm lines are calculated in the same space as the input control points.
michael@0 169 // If you transform the points the lines will also need to be transformed. This can be done
michael@0 170 // by mapping the lines with the inverse-transpose of the matrix used to map the points.
michael@0 171 void getCubicKLM(const SkPoint p[4], SkScalar klm[9]);
michael@0 172 };
michael@0 173 #endif

mercurial