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 or a GL error |
| 94 was generated. |
| 95 |
| 96 INVALID_VALUE error is generated if range is negative. |
| 97 |
| 98 INVALID_OPERATION error is generated if range does not fit in |
| 99 32-bit uint. |
| 100 |
| 101 void DeletePathsCHROMIUM(uint path, sizei range) |
| 102 |
| 103 Deletes a path object where /path/ contains /range/ names of path objects to |
| 104 be delete. After a path object is deleted, its name is again unused. |
| 105 Unused names in /paths/ are silently ignored. |
| 106 |
| 107 INVALID_VALUE error is generated if /range/ is negative. |
| 108 |
| 109 INVALID_OPERATION error is generated if /range/ does not |
| 110 fit in 32-bit uint. |
| 111 |
| 112 INVALID_OPERATION error is generated if /path/ + /range/ does not fit |
| 113 32-bit uint. |
| 114 |
| 115 boolean IsPathCHROMIUM(uint path); |
| 116 |
| 117 The query returns TRUE if /path/ is the name of a path object. If path is |
| 118 not the name of a path object, or if an error condition occurs, |
| 119 IsPathCHROMIUM returns FALSE. A name retuned by GenPathsCHROMIUM, but |
| 120 without a path specified for it yet, is not the name of a path object. |
| 121 |
| 122 void PathCommandsCHROMIUM(uint path, sizei numCommands, |
| 123 const ubyte* commands, sizei numCoords, |
| 124 enum coordType, const GLvoid* coords) |
| 125 |
| 126 Specifies a path object commands for /path/ where /numCommands/ |
| 127 indicates the number of path commands, read from the array |
| 128 /commands/, with which to initialize that path's command sequence. |
| 129 The type of the coordinates read from the /coords/ array is |
| 130 determined by the /coordType/ parameter which must be one of BYTE, |
| 131 UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT, or FLOAT, otherwise the |
| 132 INVALID_ENUM error is generated. These path commands reference |
| 133 coordinates read sequentially from the /coords/ array. |
| 134 |
| 135 The /numCommands/ elements of the /commands/ array must be tokens |
| 136 in Table 5.pathCommands. The command sequence matches |
| 137 the element order of the /commands/ array. Each command references |
| 138 a number of coordinates specified by "Coordinate count" column of |
| 139 Table 5.pathCommands, starting with the first (zero) element of |
| 140 the /coords/ array and advancing by the coordinate count for each |
| 141 command. If any of these /numCommands/ command values are not |
| 142 listed in the "Token" column of Table |
| 143 5.pathCommands, the INVALID_ENUM error is generated. |
| 144 |
| 145 The INVALID_OPERATION error is generated if /numCoords/ does not |
| 146 equal the number of coordinates referenced by the command sequence |
| 147 specified by /numCommands/ and /commands/ (so /numCoords/ provides a |
| 148 sanity check that the /coords/ array is being interpreted properly). |
| 149 The error INVALID_VALUE is generated if either /numCommands/ or |
| 150 /numCoords/ is negative. |
| 151 |
| 152 The error INVALID_OPERATION is generated if /path/ is |
| 153 not an existing path object. |
| 154 |
| 155 The error INVALID_OPERATION is generated if |
| 156 /numCommands/ + (size of /coordType/ data type) * /numCoords/ |
| 157 does not fit in 32-bit uint. |
| 158 |
| 159 If the PathCommandsCHROMIUM command results in an error, the path object |
| 160 named /path/ is not changed; if there is no error, the prior contents |
| 161 of /path/, if /path/ was an existent path object, are lost and the |
| 162 path object name /path/ becomes used. |
| 163 |
| 164 void PathParameterfCHROMIUM(uint path, enum pname, float value) |
| 165 void PathParameteriCHROMIUM(uint path, enum pname, int value) |
| 166 |
| 167 The commands specify the value of path parameters for the specified path |
| 168 object named /path/. The error INVALID_OPERATION is generated if /path/ is |
| 169 not an existing path object. |
| 170 |
| 171 Each parameter has a single (scalar) value. |
| 172 |
| 173 /pname/ must be one of the tokens in the "Name" column of |
| 174 Table 5.pathParameters. |
| 175 The required values or range of each allowed parameter name token |
| 176 is listed in Table 5.pathParameter's "Required Values/Range" column. |
| 177 |
| 178 For values of /pname/ listed in Table 5.pathsParameters, the specified |
| 179 parameter is specified by /value/ when /value/ is a float or int, |
| 180 or if /value/ is a pointer to a float or int, accessed through that |
| 181 pointer. The error INVALID_VALUE is generated if the specified |
| 182 value is negative for parameters required to be non-negative in |
| 183 Table 5.pathParameters. |
| 184 |
| 185 The error INVALID_VALUE is generated if the specified parameter value |
| 186 is not within the require range for parameters typed float or integer. |
| 187 The error INVALID_ENUM is generated if the specified parameter value |
| 188 is not one of the listed tokens for parameters typed enum. |
| 189 |
| 190 void PathStencilFuncCHROMIUM(enum func, int ref, uint mask) |
| 191 |
| 192 Configures the stencil function, stencil reference value, and stencil read |
| 193 mask to be used by the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM |
| 194 commands described subsequently. The parameters accept the same values |
| 195 allowed by the StencilFunc command. |
| 196 |
| 197 void StencilFillPathCHROMIUM(uint path, enum fillMode, uint mask) |
| 198 |
| 199 The function transforms into window space the outline of the path object |
| 200 named /path/ based on the current modelview, projection and viewport, |
| 201 transforms (ignoring any vertex and/or geometry shader or program that might |
| 202 be active/enabled) and then updates the stencil values of all /accessible |
| 203 samples/ (explained below) in the framebuffer. Each sample's stencil buffer |
| 204 value is updated based on the winding number of that sample with respect to |
| 205 the transformed outline of the path object with any non-closed subpath |
| 206 forced closed and the specified /fillMode/. |
| 207 |
| 208 If /path/ does not name an existing path object, the command does |
| 209 nothing (and no error is generated). |
| 210 |
| 211 If the path's command sequence specifies unclosed subpaths (so not |
| 212 contours) due to MOVE_TO_CHROMIUM commands, such subpaths are trivially |
| 213 closed by connecting with a line segment the initial and terminal |
| 214 control points of each such path command subsequence. |
| 215 |
| 216 Transformation of a path's outline works by taking all positions on the |
| 217 path's outline in 2D path space (x,y) and constructing an object space |
| 218 position (x,y,0,1) that is then used similar to as with the (xo,yo,zo,wo) |
| 219 position in section 2.12 ("Fixed-Function Vertex Transformation") of OpenGL |
| 220 3.2 (unabridged) Specification (Special Functions) to compute corresponding |
| 221 eye-space coordinates (xe,ye,ze,we) and clip-space coordinates |
| 222 (xc,yc,zc,wc). A path outline's clip-space coordinates are further |
| 223 transformed into window space similar to as described in section 2.16 |
| 224 ("Coordinate Transformations"). This process provides a mapping 2D path |
| 225 coordinates to 2D window coordinates. The resulting 2D window coordinates |
| 226 are undefined if any of the transformations involved are singular or may be |
| 227 inaccurate if any of the transformations (or their combination) are |
| 228 ill-conditioned. |
| 229 |
| 230 The winding number for a sample with respect to the path outline, |
| 231 transformed into window space, is computed by counting the (signed) |
| 232 number of revolutions around the sample point when traversing each |
| 233 (trivially closed if necessary) contour once in the transformed path. |
| 234 This traversal is performed in the order of the path's command |
| 235 sequence. Starting from an initially zero winding count, each |
| 236 counterclockwise revolution when the front face mode is CCW (or |
| 237 clockwise revolution when the front face mode is CW) around the sample |
| 238 point increments the winding count by one; while each clockwise |
| 239 revolution when the front face mode is CCW (or counterclockwise |
| 240 revolution when the front face mode is CW) around the sample point |
| 241 decrements the winding count by one. |
| 242 |
| 243 The /mask/ parameter controls what subset of stencil bits are affected |
| 244 by the command. |
| 245 |
| 246 The /fillMode/ parameter must be one of INVERT, COUNT_UP_CHROMIUM |
| 247 or COUNT_DOWN_CHROMIUM; otherwise the INVALID_ENUM error |
| 248 is generated. INVERT inverts the bits set in the effective /mask/ |
| 249 value for each sample's stencil value if the winding number for the |
| 250 given sample is odd. COUNT_UP_CHROMIUM adds with modulo n arithmetic the |
| 251 winding number of each sample with the sample's prior stencil buffer |
| 252 value; the result of this addition is written into the sample's |
| 253 stencil value but the bits of the stencil value not set in the |
| 254 effective /mask/ value are left unchanged. COUNT_DOWN_CHROMIUM subtracts |
| 255 with modulo /n/ arithmetic the winding number of each sample with the |
| 256 sample's prior stencil buffer value; the result of this subtraction is |
| 257 written into the sample's stencil value but the bits of the stencil |
| 258 value not set in the effective /mask/ value are left unchanged. |
| 259 |
| 260 The value of /n/ for the modulo /n/ arithmetic used by COUNT_UP_CHROMIUM |
| 261 and COUNT_DOWN_CHROMIUM is the effective /mask/+1. The error INVALID_VALUE |
| 262 is generated if /fillMode/ is COUNT_UP_CHROMIUM or COUNT_DOWN_CHROMIUM and |
| 263 the effective /mask/+1 is not an integer power of two. |
| 264 |
| 265 ACCESSIBLE SAMPLES WITH RESPECT TO A TRANSFORMED PATH |
| 266 |
| 267 The accessible samples of a transformed path that are updated are |
| 268 the samples that remain after discarding the following samples: |
| 269 |
| 270 * Any sample that would be clipped similar to as specified in section |
| 271 2.22 ("Primitive Clipping") of OpenGL 3.2 (unabridged) Specification |
| 272 (Special Functions) because its corresponding position in clip space |
| 273 (xc,yc,zc,wc) or (xe,ye,ze,we) would be clipped by the clip volume |
| 274 or enabled client-defined clip planes. |
| 275 |
| 276 * Any sample that would fail the pixel ownership test (section |
| 277 4.1.1) if rasterized. |
| 278 |
| 279 * Any sample that would fail the scissor test (section 4.1.2) |
| 280 if SCISSOR_TEST is enabled. |
| 281 |
| 282 And for the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM commands |
| 283 (so not applicable to the CoverFillPathCHROMIUM and CoverStrokePathCHROMIUM |
| 284 commands): |
| 285 * Any sample that would fail the (implicitly enabled) stencil test |
| 286 with the stencil function configured based on the path stencil |
| 287 function state configured by PathStencilFuncCHROMIUM. In the case |
| 288 of the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM |
| 289 commands, the effective stencil read |
| 290 mask for the stencil mask is treated as the value of |
| 291 PATH_STENCIL_VALUE_MASK bit-wise ANDed with the bit-invert of the |
| 292 effective /mask/ parameter value; otherwise, for the cover commands, |
| 293 the stencil test operates normally. In the case the stencil test |
| 294 fails during a path stencil operation, the stencil fail operation is |
| 295 ignored and the pixel's stencil value is left undisturbed (as if the |
| 296 stencil operation was KEEP). |
| 297 |
| 298 * The state of the face culling (CULL_FACE) enable is ignored. |
| 299 |
| 300 void StencilStrokePathCHROMIUM(uint path, int reference, uint mask) |
| 301 |
| 302 Transforms into window space the stroked region of the path object named |
| 303 /path/ based on the current modelview, projection and viewport transforms |
| 304 (ignoring any vertex and/or geometry shader or program that might be |
| 305 active/enabled) and then updates the stencil values of a subset of the |
| 306 accessible samples (see above) in the framebuffer. |
| 307 |
| 308 If /path/ does not name an existing path object, the command does |
| 309 nothing (and no error is generated). |
| 310 |
| 311 The path object's specified stroke width (in path space) determines |
| 312 the width of the path's stroked region. |
| 313 |
| 314 The stroke of a transformed path's outline |
| 315 is the region of window space defined by the union of: |
| 316 |
| 317 * Sweeping an orthogonal centered line segment of the (above |
| 318 determined) effective stroke width along each path segment |
| 319 in the path's transformed outline. |
| 320 |
| 321 * End cap regions (explained below) appended to the initial |
| 322 and terminal control points of non-closed command sequences |
| 323 in the path. For a sequence of commands that form a closed |
| 324 contour, the end cap regions are ignored. |
| 325 |
| 326 * Join style regions (explained below) between connected path |
| 327 segments meet. |
| 328 |
| 329 Any accessible samples within the union of these three regions are |
| 330 considered within the path object's stroke. |
| 331 |
| 332 If the stroke width is zero, each of the regions in the union will |
| 333 be empty and there are no accessible samples within the stroke. |
| 334 |
| 335 The /mask/ parameter controls what subset of stencil bits are affected |
| 336 by the command. |
| 337 |
| 338 A sample's stencil bits that are set in the effective /mask/ value |
| 339 are updated with the specified stencil /reference/ value if the |
| 340 sample is accessible (as specified above) and within the stroke of |
| 341 the transformed path's outline. |
| 342 |
| 343 Every path object has an end caps parameter |
| 344 PATH_END_CAPS_CHROMIUM) that is one of FLAT_CHROMIUM, |
| 345 SQUARE_CHROMIUM or ROUND_CHROMIUM. This parameter defines the |
| 346 initial and terminal caps type. There are no samples within a |
| 347 FLAT_CHROMIUM cap. The SQUARE_CHROMIUM cap extends centered and |
| 348 tangent to the given end (initial or terminal) of the subpath for |
| 349 half the effective stroke width; in other words, a square cap is a |
| 350 half-square that kisses watertightly the end of a subpath. The |
| 351 ROUND_CHROMIUM cap appends a semi-circle, centered and tangent, |
| 352 with the diameter of the effective stroke width to the given end |
| 353 (initial or terminal) of the subpath; in other words, a round cap |
| 354 is a semi-circle that kisses watertightly the end of a subpath. |
| 355 |
| 356 Every path object has a join style that is one of BEVEL_CHROMIUM, |
| 357 ROUND_CHROMIUM or MITER_REVERT_CHROMIUM. Each path object also has a miter |
| 358 limit value. The BEVEL_CHROMIUM join style inserts a triangle with two |
| 359 vertices at the outside corners where two connected path segments join and a |
| 360 third vertex at the common end point shared by the two path segments. The |
| 361 ROUND_CHROMIUM join style inserts a wedge-shaped portion of a circle |
| 362 centered at the common end point shared by the two path segments; the radius |
| 363 of the circle is half the effective stroke width. The MITER_REVERT_CHROMIUM |
| 364 join style inserts a quadrilateral with two opposite vertices at the outside |
| 365 corners where the two connected path segments join and two opposite vertices |
| 366 with one on the path's junction between the two joining path segments and |
| 367 the other at the common end point shared by the two path segments. However, |
| 368 the MITER_REVERT_CHROMIUM join style behaves as the BEVEL_CHROMIUM style if |
| 369 the sine of half the angle between the two joined segments is less than the |
| 370 path object's PATH_STROKE_WIDTH value divided by the path's |
| 371 PATH_MITER_LIMIT_CHROMIUM value. |
| 372 |
| 373 Every path object has a stroke approximation bound parameter |
| 374 (PATH_STROKE_BOUND_CHROMIUM) that is a floating-point value /sab/ clamped |
| 375 between 0.0 and 1.0 and set and queried with the PATH_STROKE_BOUND_CHROMIUM |
| 376 path parameter. Exact determination of samples swept an orthogonal |
| 377 centered line segment along cubic Bezier segments and rational |
| 378 quadratic Bezier curves (so non-circular partial elliptical arcs) is |
| 379 intractable for real-time rendering so an approximation is required; |
| 380 /sab/ intuitively bounds the approximation error as a percentage of |
| 381 the path object's stroke width. Specifically, this path parameter |
| 382 requests the implementation to stencil any samples within /sweep/ |
| 383 object space units of the exact sweep of the path's cubic Bezier |
| 384 segments or partial elliptical arcs to be sampled by the stroke where |
| 385 |
| 386 sweep = ((1-sab)*sw)/2 |
| 387 |
| 388 where /sw/ is the path object's stroke width. The initial value |
| 389 of /sab/ when a path is created is 0.2. In practical terms, this |
| 390 initial value means the stencil sample positions coverage within 80% |
| 391 (100%-20%) of the stroke width of cubic and rational quadratic stroke |
| 392 segments should be sampled. |
| 393 |
| 394 |
| 395 void CoverFillPathCHROMIUM(uint path, enum coverMode) |
| 396 |
| 397 The command transforms into window space the outline of the path object |
| 398 named /path/ based on the current modelview, projection and viewport |
| 399 transforms (ignoring any vertex and/or geometry shader or program that might |
| 400 be active/enabled) and rasterizes a subset of the accessible samples in the |
| 401 framebuffer guaranteed to include all samples that would have a net |
| 402 stencil value change if StencilFillPathCHROMIUM were issued with the same |
| 403 modelview, projection, and viewport state. During this rasterization, the |
| 404 stencil test operates normally and as configured; the expectation is the |
| 405 stencil test will be used to discard samples not determined "covered" by a |
| 406 prior StencilFillPathCHROMIUM command. |
| 407 |
| 408 If /path/ does not name an existing path object, the command does |
| 409 nothing (and no error is generated). |
| 410 |
| 411 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM. |
| 412 Otherwise, INVALID_ENUM error is generated. |
| 413 |
| 414 The subset of accessible pixels that are rasterized are within a bounding |
| 415 box (expected to be reasonably tight) surrounding all the samples guaranteed |
| 416 to be rasterized by CoverFillPathCHROMIUM. The bounding box must be |
| 417 orthogonally aligned to the path space coordinate system. (The area of the |
| 418 bounding box in path space is guaranteed to be greater than or equal the |
| 419 area of the convex hull in path space.) Each rasterized sample will be |
| 420 rasterized once and exactly once. |
| 421 |
| 422 While samples with a net stencil change /must/ be rasterized, |
| 423 implementations are explicitly allowed to vary in the rasterization |
| 424 of samples for which StencilFillPathCHROMIUM would /not/ change sample's |
| 425 net stencil value. This means implementations are allowed to (and, |
| 426 in fact, are expected to) conservatively "exceed" the region strictly |
| 427 stenciled by the path object. |
| 428 |
| 429 CoverFillPathCHROMIUM /requires/ the following rasterization invariance: |
| 430 calling CoverFillPathCHROMIUM for the same (unchanged) path object with |
| 431 fixed (unchanged) modelview, projection, and viewport transform state |
| 432 with the same (unchanged) set of accessible samples will rasterize |
| 433 the exact same set of samples with identical interpolated values |
| 434 for respective fragment/sample locations. |
| 435 |
| 436 void CoverStrokePathCHROMIUM(uint path, enum coverMode) |
| 437 |
| 438 The command operates in the same manner as CoverFillPathCHROMIUM except the |
| 439 region guaranteed to be rasterized is, rather than the region within |
| 440 /path/'s filled outline, instead the region within the /path/'s stroked |
| 441 region as determined by StencilStrokePathCHROMIUM. During this |
| 442 rasterization, the stencil test operates normally and as configured; the |
| 443 expectation is the stencil test will be used to discard samples not |
| 444 determined "covered" by a prior StencilStrokePathCHROMIUM command. |
| 445 |
| 446 If /path/ does not name an existing path object, the command does |
| 447 nothing (and no error is generated). |
| 448 |
| 449 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM. |
| 450 Otherwise, INVALID_ENUM error is generated. |
| 451 |
| 452 Analogous to the rasterization guarantee of CoverFillPathCHROMIUM with |
| 453 respect to StencilFillPathCHROMIUM, CoverStrokePathCHROMIUM guarantees that |
| 454 all samples rasterized by StencilStrokePathCHROMIUM, given the same |
| 455 transforms and accessible pixels and stroke width, will also be rasterized |
| 456 by the corresponding CoverStrokePathCHROMIUM. |
| 457 |
| 458 CoverStrokePathCHROMIUM /requires/ the following rasterization invariance: |
| 459 calling CoverStrokePathCHROMIUM for the same (unchanged) path object with |
| 460 fixed (unchanged) modelview, projection, and viewport transform state and |
| 461 with the same (unchanged) set of accessible samples will rasterize the exact |
| 462 same set of samples with identical interpolated values for respective |
| 463 fragment/sample locations. |
| 464 |
| 465 void StencilThenCoverFillPathCHROMIUM(uint path, enum fillMode, uint mask, e
num coverMode) |
| 466 |
| 467 The command is equivalent to the two commands |
| 468 |
| 469 StencilFillPathCHROMIUM(path, fillMode, mask); |
| 470 CoverFillPathCHROMIUM(path, coverMode); |
| 471 |
| 472 unless either command would generate an error; for any such error |
| 473 other than OUT_OF_MEMORY, only that error is generated. |
| 474 |
| 475 void StencilThenCoverStrokePathCHROMIUM(uint path, int reference, uint mask,
enum coverMode) |
| 476 |
| 477 The command is equivalent to the two commands |
| 478 |
| 479 StencilStrokePathCHROMIUM(path, reference, mask); |
| 480 CoverStrokePathCHROMIUM(path, coverMode); |
| 481 |
| 482 unless either command would generate an error; for any such error |
| 483 other than OUT_OF_MEMORY, only that error is generated. |
| 484 |
| 485 |
| 486 PATH COVERING RASTERIZATION DETAILS |
| 487 |
| 488 The GL processes fragments rasterized by path cover commands in |
| 489 much the same manner as fragments generated by conventional polygon |
| 490 rasterization. However path rendering /ignores/ the following |
| 491 operations: |
| 492 |
| 493 * Interpolation of per-vertex data (section 3.6.1). Path |
| 494 primitives have neither conventional vertices nor per-vertex |
| 495 data. Instead fragments generate interpolated per-fragment |
| 496 colors, texture coordinate sets, as a |
| 497 linear function of object-space or eye-space path coordinate's |
| 498 or using the current color or texture coordinate set state |
| 499 directly. |
| 500 |
| 501 Depth offset (section 3.6.2) and polygon multisample rasterization |
| 502 (3.6.3) do apply to path covering. |
| 503 |
| 504 Front and back face determination (explained in section 3.6.1 for |
| 505 polygons) operates somewhat differently for transformed paths than |
| 506 polygons. The path's convex hull or bounding box |
| 507 (depending on the /coverMode/) is specified to wind counterclockwise |
| 508 in object space, though the transformation of the convex hull into |
| 509 window space could reverse this winding. Whether the GL's front face |
| 510 state is CW or CCW (as set by the FrontFace command) determines |
| 511 if the path is front facing or not. Because the specific vertices |
| 512 that belong to the covering geometry are implementation-dependent, |
| 513 when the signed area of the covering geometry (computed with equation |
| 514 3.6) is sufficiently near zero, the facingness of the path in such |
| 515 situations is ill-defined. |
| 516 |
| 517 The determination of whether a path transformed into window space is |
| 518 front facing or not affects face culling if enabled (section 3.6.1), |
| 519 the gl_FrontFacing built-in variable (section 3.9.2), and separate |
| 520 (two-sided) stencil testing (section 4.1.4). |
| 521 |
50 Errors | 522 Errors |
51 | 523 |
52 None. | 524 None. |
53 | 525 |
54 New State | 526 New State |
55 | 527 |
56 Get Value Type Get Command Initial Description | 528 Get Value Type Get Command Initial Description |
57 ----------------------------- ----- ------------ -------- ----------------
--- | 529 ----------------------------- ----- ------------ -------- ----------------
--- |
58 PATH_MODELVIEW_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current modelvi
ew | 530 PATH_MODELVIEW_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current modelvi
ew |
59 matrix for path
rendering | 531 matrix for path
rendering |
60 PATH_PROJECTION_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current project
ion | 532 PATH_PROJECTION_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current project
ion |
61 matrix for path
rendering | 533 matrix for path
rendering |
| 534 PATH_STENCIL_FUNC_CHROMIUM Z8 GetIntegerv ALWAYS path stenciling
function |
| 535 PATH_STENCIL_REF_CHROMIUM Z+ GetIntegerv 0 path stenciling |
| 536 reference value |
| 537 PATH_STENCIL_VALUE_MASK_CHROMIUM path stencil re
ad |
| 538 Z+ GetIntegerv 1's mask |
| 539 |
| 540 Tables |
| 541 Table 5.pathCommands: Path Commands |
| 542 |
| 543 Coordinate |
| 544 Token Description count |
| 545 ========================== ===================== ========== |
| 546 MOVE_TO_CHROMIUM Absolute move 2 |
| 547 current point |
| 548 -------------------------- --------------------- ---------- |
| 549 CLOSE_PATH_CHROMIUM Close path 0 |
| 550 -------------------------- --------------------- ---------- |
| 551 LINE_TO_CHROMIUM Absolute line 2 |
| 552 -------------------------- --------------------- ---------- |
| 553 QUADRATIC_CURVE_TO_CHROMIUM Absolute quadratic 4 |
| 554 -------------------------- --------------------- ---------- |
| 555 CUBIC_CURVE_TO_CHROMIUM Absolute cubic 6 |
| 556 Bezier segment |
| 557 -------------------------- --------------------- ---------- |
| 558 CONIC_CURVE_TO_CHROMIUM Absolute conic 5 |
| 559 (rational Bezier) |
| 560 segment |
| 561 |
| 562 |
| 563 Table 5.pathParameters |
| 564 Name Type Required Values or Range |
| 565 ------------------------------- ------- ----------------------------------
------------- |
| 566 PATH_STROKE_WIDTH_CHROMIUM float non-negative |
| 567 PATH_END_CAPS_CHROMIUM enum FLAT, SQUARE_CHROMIUM, ROUND_CHROM
IUM |
| 568 PATH_JOIN_STYLE_CHROMIUM enum MITER_REVERT_CHROMIUM, BEVEL_CHROM
IUM, ROUND_CHROMIUM |
| 569 PATH_MITER_LIMIT_CHROMIUM float non-negative |
| 570 PATH_STROKE_BOUND_CHROMIUM float will be clamped to [0, 1.0], initi
ally 0.2 (20%) |
| 571 |
| 572 |
| 573 Issues |
| 574 |
| 575 1. Should there be a distinct stencil function state for path |
| 576 stenciling? |
| 577 |
| 578 RESOLVED: YES. glPathStencilFunc sets the state. How the |
| 579 stencil state needs to be configured for path covering is |
| 580 different than how the stencil function is configured typically |
| 581 for path stenciling. |
| 582 |
| 583 For example, stencil covering might use |
| 584 StencilFunc(NOT_EQUAL,0,~0) while path stenciling would |
| 585 use ALWAYS for the path stenciling stencil test. |
| 586 |
| 587 However there are other situations such as path clipping where it |
| 588 is useful to have the path stencil function configured differently |
| 589 such as PathStencilFunc(NOT_EQUAL, 0x00, 0x80) or other |
| 590 similar path clipping test. |
| 591 |
| 592 2. Since Cover*Path* skips the vertex shader, what does it mean exactly |
| 593 wrt a fully linked program? What happens to the fragment shader's input |
| 594 varyings that are not filled by the vertex shader + rasterizer? |
| 595 |
| 596 It is possible that input varyings from a shader may not be written |
| 597 as output varyings of a preceding shader. In this case, the unwritten |
| 598 input varying values are set to constant zeros. |
| 599 |
| 600 3. What is the defined behavior when stroking if PATH_STROKE_WIDTH is |
| 601 zero? |
| 602 |
| 603 There will not be any samples within the stroke. I.e. the stroke does |
| 604 not produce any visible results. |
| 605 |
| 606 4. How do you define a program that's valid to use with these calls. |
| 607 |
| 608 There is no change with respect to validity of the programs. All |
| 609 programs that are valid before this extension are valid after. |
| 610 All programs that are invalid before this extension is invalid |
| 611 after. |
| 612 |
| 613 5. Can same programs be used to render regular GL primitives as well |
| 614 as in covering paths? |
| 615 |
| 616 Yes. |
| 617 |
| 618 6. How is the fragment shader called when covering paths, and with |
| 619 which values for the inputs? |
| 620 |
| 621 gl_FragCoord: Interpolated coordinate of the path coverage. |
| 622 |
| 623 gl_FrontFacing: |
| 624 * Paths wind by default counterclockwise |
| 625 * Window space transform can reverse this winding |
| 626 * GL front face state CW/CCW selects whether the variable is true |
| 627 or false |
| 628 |
| 629 user-defined varyings: constant zeros. |
62 | 630 |
63 Revision History | 631 Revision History |
64 | 632 |
65 14/8/2014 Documented the extension | 633 14/8/2014 Documented the extension |
OLD | NEW |