OLD | NEW |
1 Name | 1 Name |
2 | 2 |
3 CHROMIUM_path_rendering | 3 CHROMIUM_path_rendering |
4 | 4 |
5 Name Strings | 5 Name Strings |
6 | 6 |
7 GL_CHROMIUM_path_rendering | 7 GL_CHROMIUM_path_rendering |
8 | 8 |
9 Version | 9 Version |
10 | 10 |
11 Last Modifed Date: August 14, 2014 | 11 Last Modifed Date: August 14, 2014 |
12 | 12 |
13 Dependencies | 13 Dependencies |
14 | 14 |
15 OpenGL ES 3.0 is required. | 15 OpenGL ES 3.0 is required. |
16 | 16 |
17 Overview | 17 Overview |
18 | 18 |
19 This extensions implements path rendering using | 19 This extensions implements path rendering using |
20 OpenGL API. | 20 OpenGL API. |
21 | 21 |
22 New Tokens | 22 New Tokens |
23 | 23 |
24 Accepted by the <matrixMode> parameter of MatrixLoadfCHROMIUM and | 24 Accepted by the <matrixMode> parameter of MatrixLoadfCHROMIUM and |
25 MatrixLoadIdentityCHROMIUM: | 25 MatrixLoadIdentityCHROMIUM: |
26 PATH_MODELVIEW_CHROMIUM 0x1700 | 26 PATH_MODELVIEW_CHROMIUM 0x1700 |
27 PATH_PROJECTION_CHROMIUM 0x1701 | 27 PATH_PROJECTION_CHROMIUM 0x1701 |
28 | 28 |
| 29 Accepted in elements of the <commands> array parameter of |
| 30 PathCommandsCHROMIUM: |
| 31 CLOSE_PATH_CHROMIUM 0x00 |
| 32 MOVE_TO_CHROMIUM 0x02 |
| 33 LINE_TO_CHROMIUM 0x04 |
| 34 QUADRATIC_CURVE_TO_CHROMIUM 0x0A |
| 35 CUBIC_CURVE_TO_CHROMIUM 0x0C |
| 36 CONIC_CURVE_TO_CHROMIUM 0x1A |
| 37 |
29 Accepted by the <pname> parameter of GetIntegerv, | 38 Accepted by the <pname> parameter of GetIntegerv, |
30 GetFloatv: | 39 GetFloatv: |
31 PATH_MODELVIEW_MATRIX_CHROMIUM 0x0BA6 | 40 PATH_MODELVIEW_MATRIX_CHROMIUM 0x0BA6 |
32 PATH_PROJECTION_MATRIX_CHROMIUM 0x0BA7 | 41 PATH_PROJECTION_MATRIX_CHROMIUM 0x0BA7 |
33 | 42 |
| 43 Accepted by the <pname> parameter of PathParameter{if}CHROMIUM: |
| 44 PATH_STROKE_WIDTH_CHROMIUM 0x9075 |
| 45 PATH_END_CAPS_CHROMIUM 0x9076 |
| 46 PATH_JOIN_STYLE_CHROMIUM 0x9079 |
| 47 PATH_MITER_LIMIT_CHROMIUM 0x907a |
| 48 PATH_STROKE_BOUND_CHROMIUM 0x9086 |
| 49 |
| 50 Accepted by the <value> parameter of PathParameter{if}CHROMIUM: |
| 51 FLAT_CHROMIUM 0x1D00 |
| 52 SQUARE_CHROMIUM 0x90a3 |
| 53 ROUND_CHROMIUM 0x90a4 |
| 54 BEVEL_CHROMIUM 0x90A6 |
| 55 MITER_REVERT_CHROMIUM 0x90A7 |
| 56 |
| 57 Accepted by the <fillMode> parameter of StencilFillPathCHROMIUM: |
| 58 COUNT_UP_CHROMIUM 0x9088 |
| 59 COUNT_DOWN_CHROMIUM 0x9089 |
| 60 |
| 61 Accepted by the <coverMode> parameter of CoverFillPathCHROMIUM, |
| 62 CoverStrokePath, StencilThenCoverFillPathCHROMIUM and |
| 63 StencilThenCoverStrokePathCHROMIUM: |
| 64 CONVEX_HULL_CHROMIUM 0x908B |
| 65 BOUNDING_BOX_CHROMIUM 0x908D |
| 66 |
34 | 67 |
35 New Procedures and Functions | 68 New Procedures and Functions |
36 | 69 |
37 void MatrixLoadfCHROMIUM(enum matrixMode, float* matrix) | 70 void MatrixLoadfCHROMIUM(enum matrixMode, float* matrix) |
38 | 71 |
39 Takes a pointer to a 4x4 matrix stored in column-major order as 16 | 72 Takes a pointer to a 4x4 matrix stored in column-major order as 16 |
40 consecutive floating-point values. The matrixMode specifies which | 73 consecutive floating-point values. The matrixMode specifies which |
41 matrix, PATH_MODELVIEW_CHROMIUM or PATH_PROJECTION_CHROMIUM is used. | 74 matrix, PATH_MODELVIEW_CHROMIUM or PATH_PROJECTION_CHROMIUM is used. |
42 | 75 |
43 The funcition specifies either modelview or projection matrix | 76 The funcition specifies either modelview or projection matrix |
44 to be used with path rendering API calls. | 77 to be used with path rendering API calls. |
45 | 78 |
46 void MatrixLoadIdentityCHROMIUM(enum matrixMode) | 79 void MatrixLoadIdentityCHROMIUM(enum matrixMode) |
47 | 80 |
48 Effectively calls MatrixLoadf with the identity matrix. | 81 Effectively calls MatrixLoadf with the identity matrix. |
49 | 82 |
| 83 uint GenPathsCHROMIUM(sizei range) |
| 84 |
| 85 Returns an integer /n/ such that names /n/, ..., /n+range-1/ are |
| 86 previously unused (i.e. there are /range/ previously unused path object |
| 87 names starting at /n/). These names are marked as used, for the |
| 88 purposes of subsequent GenPathsCHROMIUM only, but they do not acquire |
| 89 path object state until each particular name is used to specify |
| 90 a path object. |
| 91 |
| 92 Returns 0 if no new path name was marked as used. Reasons for this |
| 93 include lack of free path names or range being 0. |
| 94 |
| 95 void DeletePathsCHROMIUM(uint path, sizei range) |
| 96 |
| 97 Deletes a path object where /path/ contains /range/ names of path objects to |
| 98 be delete. After a path object is deleted, its name is again unused. |
| 99 Unused names in /paths/ are silently ignored. |
| 100 |
| 101 boolean IsPathCHROMIUM(uint path); |
| 102 |
| 103 The query returns TRUE if /path/ is the name of a path object. If path is |
| 104 not the name of a path object, or if an error condition occurs, |
| 105 IsPathCHROMIUM returns FALSE. A name retuned by GenPathsCHROMIUM, but |
| 106 without a path specified for it yet, is not the name of a path object. |
| 107 |
| 108 void PathCommandsCHROMIUM(uint path, sizei numCommands, |
| 109 const ubyte* commands, sizei numCoords, |
| 110 enum coordType, const GLvoid* coords) |
| 111 |
| 112 Specifies a path object commands for /path/ where /numCommands/ |
| 113 indicates the number of path commands, read from the array |
| 114 /commands/, with which to initialize that path's command sequence. |
| 115 The type of the coordinates read from the /coords/ array is |
| 116 determined by the /coordType/ parameter which must be one of BYTE, |
| 117 UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT, or FLOAT, otherwise the |
| 118 INVALID_ENUM error is generated. These path commands reference |
| 119 coordinates read sequentially from the /coords/ array. |
| 120 |
| 121 The /numCommands/ elements of the /commands/ array must be tokens |
| 122 in Table 5.pathCommands. The command sequence matches |
| 123 the element order of the /commands/ array. Each command references |
| 124 a number of coordinates specified by "Coordinate count" column of |
| 125 Table 5.pathCommands, starting with the first (zero) element of |
| 126 the /coords/ array and advancing by the coordinate count for each |
| 127 command. If any of these /numCommands/ command values are not |
| 128 listed in the "Token" column of Table |
| 129 5.pathCommands, the INVALID_ENUM error is generated. |
| 130 |
| 131 The INVALID_OPERATION error is generated if /numCoords/ does not |
| 132 equal the number of coordinates referenced by the command sequence |
| 133 specified by /numCommands/ and /commands/ (so /numCoords/ provides a |
| 134 sanity check that the /coords/ array is being interpreted properly). |
| 135 The error INVALID_VALUE is generated if either /numCommands/ or |
| 136 /numCoords/ is negative. |
| 137 |
| 138 The error INVALID_OPERATION is generated if /path/ is |
| 139 not an existing path object. |
| 140 |
| 141 If the PathCommandsCHROMIUM command results in an error, the path object |
| 142 named /path/ is not changed; if there is no error, the prior contents |
| 143 of /path/, if /path/ was an existent path object, are lost and the |
| 144 path object name /path/ becomes used. |
| 145 |
| 146 void PathParameterfCHROMIUM(uint path, enum pname, float value) |
| 147 void PathParameteriCHROMIUM(uint path, enum pname, int value) |
| 148 |
| 149 The commands specify the value of path parameters for the specified path |
| 150 object named /path/. The error INVALID_OPERATION is generated if /path/ is |
| 151 not an existing path object. |
| 152 |
| 153 Each parameter has a single (scalar) value. |
| 154 |
| 155 /pname/ must be one of the tokens in the "Name" column of |
| 156 Table 5.pathParameters. |
| 157 The required values or range of each allowed parameter name token |
| 158 is listed in Table 5.pathParameter's "Required Values/Range" column. |
| 159 |
| 160 For values of /pname/ listed in Table 5.pathsParameters, the specified |
| 161 parameter is specified by /value/ when /value/ is a float or int, |
| 162 or if /value/ is a pointer to a float or int, accessed through that |
| 163 pointer. The error INVALID_VALUE is generated if the specified |
| 164 value is negative for parameters required to be non-negative in |
| 165 Table 5.pathParameters. |
| 166 |
| 167 The error INVALID_VALUE is generated if the specified parameter value |
| 168 is not within the require range for parameters typed float or integer. |
| 169 The error INVALID_ENUM is generated if the specified parameter value |
| 170 is not one of the listed tokens for parameters typed enum. |
| 171 |
| 172 void PathStencilFuncCHROMIUM(enum func, int ref, uint mask) |
| 173 |
| 174 Configures the stencil function, stencil reference value, and stencil read |
| 175 mask to be used by the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM |
| 176 commands described subsequently. The parameters accept the same values |
| 177 allowed by the StencilFunc command. |
| 178 |
| 179 void StencilFillPathCHROMIUM(uint path, enum fillMode, uint mask) |
| 180 |
| 181 The function transforms into window space the outline of the path object |
| 182 named /path/ based on the current modelview, projection and viewport, |
| 183 transforms (ignoring any vertex and/or geometry shader or program that might |
| 184 be active/enabled) and then updates the stencil values of all /accessible |
| 185 samples/ (explained below) in the framebuffer. Each sample's stencil buffer |
| 186 value is updated based on the winding number of that sample with respect to |
| 187 the transformed outline of the path object with any non-closed subpath |
| 188 forced closed and the specified /fillMode/. |
| 189 |
| 190 If /path/ does not name an existing path object, the command does |
| 191 nothing (and no error is generated). |
| 192 |
| 193 If the path's command sequence specifies unclosed subpaths (so not |
| 194 contours) due to MOVE_TO_CHROMIUM commands, such subpaths are trivially |
| 195 closed by connecting with a line segment the initial and terminal |
| 196 control points of each such path command subsequence. |
| 197 |
| 198 Transformation of a path's outline works by taking all positions on the |
| 199 path's outline in 2D path space (x,y) and constructing an object space |
| 200 position (x,y,0,1) that is then used similar to as with the (xo,yo,zo,wo) |
| 201 position in section 2.12 ("Fixed-Function Vertex Transformation") of OpenGL |
| 202 3.2 (unabridged) Specification (Special Functions) to compute corresponding |
| 203 eye-space coordinates (xe,ye,ze,we) and clip-space coordinates |
| 204 (xc,yc,zc,wc). A path outline's clip-space coordinates are further |
| 205 transformed into window space similar to as described in section 2.16 |
| 206 ("Coordinate Transformations"). This process provides a mapping 2D path |
| 207 coordinates to 2D window coordinates. The resulting 2D window coordinates |
| 208 are undefined if any of the transformations involved are singular or may be |
| 209 inaccurate if any of the transformations (or their combination) are |
| 210 ill-conditioned. |
| 211 |
| 212 The winding number for a sample with respect to the path outline, |
| 213 transformed into window space, is computed by counting the (signed) |
| 214 number of revolutions around the sample point when traversing each |
| 215 (trivially closed if necessary) contour once in the transformed path. |
| 216 This traversal is performed in the order of the path's command |
| 217 sequence. Starting from an initially zero winding count, each |
| 218 counterclockwise revolution when the front face mode is CCW (or |
| 219 clockwise revolution when the front face mode is CW) around the sample |
| 220 point increments the winding count by one; while each clockwise |
| 221 revolution when the front face mode is CCW (or counterclockwise |
| 222 revolution when the front face mode is CW) around the sample point |
| 223 decrements the winding count by one. |
| 224 |
| 225 The /mask/ parameter controls what subset of stencil bits are affected |
| 226 by the command. |
| 227 |
| 228 The /fillMode/ parameter must be one of INVERT, COUNT_UP_CHROMIUM |
| 229 or COUNT_DOWN_CHROMIUM; otherwise the INVALID_ENUM error |
| 230 is generated. INVERT inverts the bits set in the effective /mask/ |
| 231 value for each sample's stencil value if the winding number for the |
| 232 given sample is odd. COUNT_UP_CHROMIUM adds with modulo n arithmetic the |
| 233 winding number of each sample with the sample's prior stencil buffer |
| 234 value; the result of this addition is written into the sample's |
| 235 stencil value but the bits of the stencil value not set in the |
| 236 effective /mask/ value are left unchanged. COUNT_DOWN_CHROMIUM subtracts |
| 237 with modulo /n/ arithmetic the winding number of each sample with the |
| 238 sample's prior stencil buffer value; the result of this subtraction is |
| 239 written into the sample's stencil value but the bits of the stencil |
| 240 value not set in the effective /mask/ value are left unchanged. |
| 241 |
| 242 The value of /n/ for the modulo /n/ arithmetic used by COUNT_UP_CHROMIUM |
| 243 and COUNT_DOWN_CHROMIUM is the effective /mask/+1. The error INVALID_VALUE |
| 244 is generated if /fillMode/ is COUNT_UP_CHROMIUM or COUNT_DOWN_CHROMIUM and |
| 245 the effective /mask/+1 is not an integer power of two. |
| 246 |
| 247 ACCESSIBLE SAMPLES WITH RESPECT TO A TRANSFORMED PATH |
| 248 |
| 249 The accessible samples of a transformed path that are updated are |
| 250 the samples that remain after discarding the following samples: |
| 251 |
| 252 * Any sample that would be clipped similar to as specified in section |
| 253 2.22 ("Primitive Clipping") of OpenGL 3.2 (unabridged) Specification |
| 254 (Special Functions) because its corresponding position in clip space |
| 255 (xc,yc,zc,wc) or (xe,ye,ze,we) would be clipped by the clip volume |
| 256 or enabled client-defined clip planes. |
| 257 |
| 258 * Any sample that would fail the pixel ownership test (section |
| 259 4.1.1) if rasterized. |
| 260 |
| 261 * Any sample that would fail the scissor test (section 4.1.2) |
| 262 if SCISSOR_TEST is enabled. |
| 263 |
| 264 And for the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM commands |
| 265 (so not applicable to the CoverFillPathCHROMIUM and CoverStrokePathCHROMIUM |
| 266 commands): |
| 267 * Any sample that would fail the (implicitly enabled) stencil test |
| 268 with the stencil function configured based on the path stencil |
| 269 function state configured by PathStencilFuncCHROMIUM. In the case |
| 270 of the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM |
| 271 commands, the effective stencil read |
| 272 mask for the stencil mask is treated as the value of |
| 273 PATH_STENCIL_VALUE_MASK bit-wise ANDed with the bit-invert of the |
| 274 effective /mask/ parameter value; otherwise, for the cover commands, |
| 275 the stencil test operates normally. In the case the stencil test |
| 276 fails during a path stencil operation, the stencil fail operation is |
| 277 ignored and the pixel's stencil value is left undisturbed (as if the |
| 278 stencil operation was KEEP). |
| 279 |
| 280 * The state of the face culling (CULL_FACE) enable is ignored. |
| 281 |
| 282 void StencilStrokePathCHROMIUM(uint path, int reference, uint mask) |
| 283 |
| 284 Transforms into window space the stroked region of the path object named |
| 285 /path/ based on the current modelview, projection and viewport transforms |
| 286 (ignoring any vertex and/or geometry shader or program that might be |
| 287 active/enabled) and then updates the stencil values of a subset of the |
| 288 accessible samples (see above) in the framebuffer. |
| 289 |
| 290 If /path/ does not name an existing path object, the command does |
| 291 nothing (and no error is generated). |
| 292 |
| 293 The path object's specified stroke width (in path space) determines |
| 294 the width of the path's stroked region. |
| 295 |
| 296 The stroke of a transformed path's outline |
| 297 is the region of window space defined by the union of: |
| 298 |
| 299 * Sweeping an orthogonal centered line segment of the (above |
| 300 determined) effective stroke width along each path segment |
| 301 in the path's transformed outline. |
| 302 |
| 303 * End cap regions (explained below) appended to the initial |
| 304 and terminal control points of non-closed command sequences |
| 305 in the path. For a sequence of commands that form a closed |
| 306 contour, the end cap regions are ignored. |
| 307 |
| 308 * Join style regions (explained below) between connected path |
| 309 segments meet. |
| 310 |
| 311 Any accessible samples within the union of these three regions are |
| 312 considered within the path object's stroke. |
| 313 |
| 314 If the stroke width is zero, each of the regions in the union will |
| 315 be empty and there are no accessible samples within the stroke. |
| 316 |
| 317 The /mask/ parameter controls what subset of stencil bits are affected |
| 318 by the command. |
| 319 |
| 320 A sample's stencil bits that are set in the effective /mask/ value |
| 321 are updated with the specified stencil /reference/ value if the |
| 322 sample is accessible (as specified above) and within the stroke of |
| 323 the transformed path's outline. |
| 324 |
| 325 Every path object has an end caps parameter |
| 326 PATH_END_CAPS_CHROMIUM) that is one of FLAT_CHROMIUM, |
| 327 SQUARE_CHROMIUM or ROUND_CHROMIUM. This parameter defines the |
| 328 initial and terminal caps type. There are no samples within a |
| 329 FLAT_CHROMIUM cap. The SQUARE_CHROMIUM cap extends centered and |
| 330 tangent to the given end (initial or terminal) of the subpath for |
| 331 half the effective stroke width; in other words, a square cap is a |
| 332 half-square that kisses watertightly the end of a subpath. The |
| 333 ROUND_CHROMIUM cap appends a semi-circle, centered and tangent, |
| 334 with the diameter of the effective stroke width to the given end |
| 335 (initial or terminal) of the subpath; in other words, a round cap |
| 336 is a semi-circle that kisses watertightly the end of a subpath. |
| 337 |
| 338 Every path object has a join style that is one of BEVEL_CHROMIUM, |
| 339 ROUND_CHROMIUM or MITER_REVERT_CHROMIUM. Each path object also has a miter |
| 340 limit value. The BEVEL_CHROMIUM join style inserts a triangle with two |
| 341 vertices at the outside corners where two connected path segments join and a |
| 342 third vertex at the common end point shared by the two path segments. The |
| 343 ROUND_CHROMIUM join style inserts a wedge-shaped portion of a circle |
| 344 centered at the common end point shared by the two path segments; the radius |
| 345 of the circle is half the effective stroke width. The MITER_REVERT_CHROMIUM |
| 346 join style inserts a quadrilateral with two opposite vertices at the outside |
| 347 corners where the two connected path segments join and two opposite vertices |
| 348 with one on the path's junction between the two joining path segments and |
| 349 the other at the common end point shared by the two path segments. However, |
| 350 the MITER_REVERT_CHROMIUM join style behaves as the BEVEL_CHROMIUM style if |
| 351 the sine of half the angle between the two joined segments is less than the |
| 352 path object's PATH_STROKE_WIDTH value divided by the path's |
| 353 PATH_MITER_LIMIT_CHROMIUM value. |
| 354 |
| 355 Every path object has a stroke approximation bound parameter |
| 356 (PATH_STROKE_BOUND_CHROMIUM) that is a floating-point value /sab/ clamped |
| 357 between 0.0 and 1.0 and set and queried with the PATH_STROKE_BOUND_CHROMIUM |
| 358 path parameter. Exact determination of samples swept an orthogonal |
| 359 centered line segment along cubic Bezier segments and rational |
| 360 quadratic Bezier curves (so non-circular partial elliptical arcs) is |
| 361 intractable for real-time rendering so an approximation is required; |
| 362 /sab/ intuitively bounds the approximation error as a percentage of |
| 363 the path object's stroke width. Specifically, this path parameter |
| 364 requests the implementation to stencil any samples within /sweep/ |
| 365 object space units of the exact sweep of the path's cubic Bezier |
| 366 segments or partial elliptical arcs to be sampled by the stroke where |
| 367 |
| 368 sweep = ((1-sab)*sw)/2 |
| 369 |
| 370 where /sw/ is the path object's stroke width. The initial value |
| 371 of /sab/ when a path is created is 0.2. In practical terms, this |
| 372 initial value means the stencil sample positions coverage within 80% |
| 373 (100%-20%) of the stroke width of cubic and rational quadratic stroke |
| 374 segments should be sampled. |
| 375 |
| 376 |
| 377 void CoverFillPathCHROMIUM(uint path, enum coverMode) |
| 378 |
| 379 The command transforms into window space the outline of the path object |
| 380 named /path/ based on the current modelview, projection and viewport |
| 381 transforms (ignoring any vertex and/or geometry shader or program that might |
| 382 be active/enabled) and rasterizes a subset of the accessible samples in the |
| 383 framebuffer guaranteed to include all samples that would have a net |
| 384 stencil value change if StencilFillPathCHROMIUM were issued with the same |
| 385 modelview, projection, and viewport state. During this rasterization, the |
| 386 stencil test operates normally and as configured; the expectation is the |
| 387 stencil test will be used to discard samples not determined "covered" by a |
| 388 prior StencilFillPathCHROMIUM command. |
| 389 |
| 390 If /path/ does not name an existing path object, the command does |
| 391 nothing (and no error is generated). |
| 392 |
| 393 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM. |
| 394 Otherwise, INVALID_ENUM error is generated. |
| 395 |
| 396 The subset of accessible pixels that are rasterized are within a bounding |
| 397 box (expected to be reasonably tight) surrounding all the samples guaranteed |
| 398 to be rasterized by CoverFillPathCHROMIUM. The bounding box must be |
| 399 orthogonally aligned to the path space coordinate system. (The area of the |
| 400 bounding box in path space is guaranteed to be greater than or equal the |
| 401 area of the convex hull in path space.) Each rasterized sample will be |
| 402 rasterized once and exactly once. |
| 403 |
| 404 While samples with a net stencil change /must/ be rasterized, |
| 405 implementations are explicitly allowed to vary in the rasterization |
| 406 of samples for which StencilFillPathCHROMIUM would /not/ change sample's |
| 407 net stencil value. This means implementations are allowed to (and, |
| 408 in fact, are expected to) conservatively "exceed" the region strictly |
| 409 stenciled by the path object. |
| 410 |
| 411 CoverFillPathCHROMIUM /requires/ the following rasterization invariance: |
| 412 calling CoverFillPathCHROMIUM for the same (unchanged) path object with |
| 413 fixed (unchanged) modelview, projection, and viewport transform state |
| 414 with the same (unchanged) set of accessible samples will rasterize |
| 415 the exact same set of samples with identical interpolated values |
| 416 for respective fragment/sample locations. |
| 417 |
| 418 void CoverStrokePathCHROMIUM(uint path, enum coverMode) |
| 419 |
| 420 The command operates in the same manner as CoverFillPathCHROMIUM except the |
| 421 region guaranteed to be rasterized is, rather than the region within |
| 422 /path/'s filled outline, instead the region within the /path/'s stroked |
| 423 region as determined by StencilStrokePathCHROMIUM. During this |
| 424 rasterization, the stencil test operates normally and as configured; the |
| 425 expectation is the stencil test will be used to discard samples not |
| 426 determined "covered" by a prior StencilStrokePathCHROMIUM command. |
| 427 |
| 428 If /path/ does not name an existing path object, the command does |
| 429 nothing (and no error is generated). |
| 430 |
| 431 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM. |
| 432 Otherwise, INVALID_ENUM error is generated. |
| 433 |
| 434 Analogous to the rasterization guarantee of CoverFillPathCHROMIUM with |
| 435 respect to StencilFillPathCHROMIUM, CoverStrokePathCHROMIUM guarantees that |
| 436 all samples rasterized by StencilStrokePathCHROMIUM, given the same |
| 437 transforms and accessible pixels and stroke width, will also be rasterized |
| 438 by the corresponding CoverStrokePathCHROMIUM. |
| 439 |
| 440 CoverStrokePathCHROMIUM /requires/ the following rasterization invariance: |
| 441 calling CoverStrokePathCHROMIUM for the same (unchanged) path object with |
| 442 fixed (unchanged) modelview, projection, and viewport transform state and |
| 443 with the same (unchanged) set of accessible samples will rasterize the exact |
| 444 same set of samples with identical interpolated values for respective |
| 445 fragment/sample locations. |
| 446 |
| 447 void StencilThenCoverFillPathCHROMIUM(uint path, enum fillMode, uint mask, e
num coverMode) |
| 448 |
| 449 The command is equivalent to the two commands |
| 450 |
| 451 StencilFillPathCHROMIUM(path, fillMode, mask); |
| 452 CoverFillPathCHROMIUM(path, coverMode); |
| 453 |
| 454 unless either command would generate an error; for any such error |
| 455 other than OUT_OF_MEMORY, only that error is generated. |
| 456 |
| 457 void StencilThenCoverStrokePathCHROMIUM(uint path, int reference, uint mask,
enum coverMode) |
| 458 |
| 459 The command is equivalent to the two commands |
| 460 |
| 461 StencilStrokePathCHROMIUM(path, reference, mask); |
| 462 CoverStrokePathCHROMIUM(path, coverMode); |
| 463 |
| 464 unless either command would generate an error; for any such error |
| 465 other than OUT_OF_MEMORY, only that error is generated. |
| 466 |
| 467 |
50 Errors | 468 Errors |
51 | 469 |
52 None. | 470 None. |
53 | 471 |
54 New State | 472 New State |
55 | 473 |
56 Get Value Type Get Command Initial Description | 474 Get Value Type Get Command Initial Description |
57 ----------------------------- ----- ------------ -------- ----------------
--- | 475 ----------------------------- ----- ------------ -------- ----------------
--- |
58 PATH_MODELVIEW_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current modelvi
ew | 476 PATH_MODELVIEW_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current modelvi
ew |
59 matrix for path
rendering | 477 matrix for path
rendering |
60 PATH_PROJECTION_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current project
ion | 478 PATH_PROJECTION_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current project
ion |
61 matrix for path
rendering | 479 matrix for path
rendering |
| 480 PATH_STENCIL_FUNC_CHROMIUM Z8 GetIntegerv ALWAYS path stenciling
function |
| 481 PATH_STENCIL_REF_CHROMIUM Z+ GetIntegerv 0 path stenciling |
| 482 reference value |
| 483 PATH_STENCIL_VALUE_MASK_CHROMIUM path stencil re
ad |
| 484 Z+ GetIntegerv 1's mask |
| 485 |
| 486 Tables |
| 487 Table 5.pathCommands: Path Commands |
| 488 |
| 489 Coordinate |
| 490 Token Description count |
| 491 ========================== ===================== ========== |
| 492 MOVE_TO_CHROMIUM Absolute move 2 |
| 493 current point |
| 494 -------------------------- --------------------- ---------- |
| 495 CLOSE_PATH_CHROMIUM Close path 0 |
| 496 -------------------------- --------------------- ---------- |
| 497 LINE_TO_CHROMIUM Absolute line 2 |
| 498 -------------------------- --------------------- ---------- |
| 499 QUADRATIC_CURVE_TO_CHROMIUM Absolute quadratic 4 |
| 500 -------------------------- --------------------- ---------- |
| 501 CUBIC_CURVE_TO_CHROMIUM Absolute cubic 6 |
| 502 Bezier segment |
| 503 -------------------------- --------------------- ---------- |
| 504 CONIC_CURVE_TO_CHROMIUM Absolute conic 5 |
| 505 (rational Bezier) |
| 506 segment |
| 507 |
| 508 |
| 509 Table 5.pathParameters |
| 510 Name Type Required Values or Range |
| 511 ------------------------------- ------- ----------------------------------
------------- |
| 512 PATH_STROKE_WIDTH_CHROMIUM float non-negative |
| 513 PATH_END_CAPS_CHROMIUM enum FLAT, SQUARE_CHROMIUM, ROUND_CHROM
IUM |
| 514 PATH_JOIN_STYLE_CHROMIUM enum MITER_REVERT_CHROMIUM, BEVEL_CHROM
IUM, ROUND_CHROMIUM |
| 515 PATH_MITER_LIMIT_CHROMIUM float non-negative |
| 516 PATH_STROKE_BOUND_CHROMIUM float will be clamped to [0, 1.0], initi
ally 0.2 (20%) |
| 517 |
| 518 |
| 519 Issues |
| 520 |
| 521 1. Should there be a distinct stencil function state for path |
| 522 stenciling? |
| 523 |
| 524 RESOLVED: YES. glPathStencilFunc sets the state. How the |
| 525 stencil state needs to be configured for path covering is |
| 526 different than how the stencil function is configured typically |
| 527 for path stenciling. |
| 528 |
| 529 For example, stencil covering might use |
| 530 StencilFunc(NOT_EQUAL,0,~0) while path stenciling would |
| 531 use ALWAYS for the path stenciling stencil test. |
| 532 |
| 533 However there are other situations such as path clipping where it |
| 534 is useful to have the path stencil function configured differently |
| 535 such as PathStencilFunc(NOT_EQUAL, 0x00, 0x80) or other |
| 536 similar path clipping test. |
| 537 |
| 538 2. Since my Cover*Path* skips the vertex shader, what does it mean exactly |
| 539 wrt a fully linked program? What happens to the fragment shader's input |
| 540 varyings that are not filled by the vertex shader + rasterizer? |
| 541 |
| 542 It is possible that input varyings from a shader may not be written |
| 543 as output varyings of a preceding shader. In this case, the unwritten |
| 544 input varying values are undefined. Implementations are encouraged to |
| 545 zero these undefined input varying values. |
| 546 |
| 547 3. What is the defined behavior when stroking if PATH_STROKE_WIDTH is |
| 548 zero? |
| 549 |
| 550 There will not be any samples within the stroke. I.e. the stroke does |
| 551 not produce any visible results. |
62 | 552 |
63 Revision History | 553 Revision History |
64 | 554 |
65 14/8/2014 Documented the extension | 555 14/8/2014 Documented the extension |
OLD | NEW |