| blob | 824ee916aca76c4af35fcb0ce627f118d0fb8324 |
1 Name
3 CHROMIUM_path_rendering
5 Name Strings
7 GL_CHROMIUM_path_rendering
9 Version
11 Last Modifed Date: August 14, 2014
13 Dependencies
15 OpenGL ES 3.0 is required.
17 Overview
19 This extensions implements path rendering using
20 OpenGL API.
22 New Tokens
24 Accepted by the <matrixMode> parameter of MatrixLoadfCHROMIUM and
25 MatrixLoadIdentityCHROMIUM:
26 PATH_MODELVIEW_CHROMIUM 0x1700
27 PATH_PROJECTION_CHROMIUM 0x1701
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
38 Accepted by the <pname> parameter of GetIntegerv,
39 GetFloatv:
40 PATH_MODELVIEW_MATRIX_CHROMIUM 0x0BA6
41 PATH_PROJECTION_MATRIX_CHROMIUM 0x0BA7
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
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
57 Accepted by the <fillMode> parameter of StencilFillPathCHROMIUM:
58 COUNT_UP_CHROMIUM 0x9088
59 COUNT_DOWN_CHROMIUM 0x9089
61 Accepted by the <coverMode> parameter of CoverFillPathCHROMIUM,
62 CoverStrokePath, StencilThenCoverFillPathCHROMIUM and
63 StencilThenCoverStrokePathCHROMIUM:
64 CONVEX_HULL_CHROMIUM 0x908B
65 BOUNDING_BOX_CHROMIUM 0x908D
68 New Procedures and Functions
70 void MatrixLoadfCHROMIUM(enum matrixMode, float* matrix)
72 Takes a pointer to a 4x4 matrix stored in column-major order as 16
73 consecutive floating-point values. The matrixMode specifies which
74 matrix, PATH_MODELVIEW_CHROMIUM or PATH_PROJECTION_CHROMIUM is used.
76 The funcition specifies either modelview or projection matrix
77 to be used with path rendering API calls.
79 void MatrixLoadIdentityCHROMIUM(enum matrixMode)
81 Effectively calls MatrixLoadf with the identity matrix.
83 uint GenPathsCHROMIUM(sizei range)
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.
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.
96 INVALID_VALUE error is generated if range is negative.
98 INVALID_OPERATION error is generated if range does not fit in
99 32-bit uint.
101 void DeletePathsCHROMIUM(uint path, sizei range)
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.
107 INVALID_VALUE error is generated if /range/ is negative.
109 INVALID_OPERATION error is generated if /range/ does not
110 fit in 32-bit uint.
112 INVALID_OPERATION error is generated if /path/ + /range/ does not fit
113 32-bit uint.
115 boolean IsPathCHROMIUM(uint path);
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.
122 void PathCommandsCHROMIUM(uint path, sizei numCommands,
123 const ubyte* commands, sizei numCoords,
124 enum coordType, const GLvoid* coords)
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.
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.
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.
152 The error INVALID_OPERATION is generated if /path/ is
153 not an existing path object.
155 The error INVALID_OPERATION is generated if
156 /numCommands/ + (size of /coordType/ data type) * /numCoords/
157 does not fit in 32-bit uint.
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.
164 void PathParameterfCHROMIUM(uint path, enum pname, float value)
165 void PathParameteriCHROMIUM(uint path, enum pname, int value)
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.
171 Each parameter has a single (scalar) value.
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.
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.
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.
190 void PathStencilFuncCHROMIUM(enum func, int ref, uint mask)
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.
197 void StencilFillPathCHROMIUM(uint path, enum fillMode, uint mask)
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/.
208 If /path/ does not name an existing path object, the command does
209 nothing (and no error is generated).
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.
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.
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.
243 The /mask/ parameter controls what subset of stencil bits are affected
244 by the command.
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.
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.
265 ACCESSIBLE SAMPLES WITH RESPECT TO A TRANSFORMED PATH
267 The accessible samples of a transformed path that are updated are
268 the samples that remain after discarding the following samples:
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.
276 * Any sample that would fail the pixel ownership test (section
277 4.1.1) if rasterized.
279 * Any sample that would fail the scissor test (section 4.1.2)
280 if SCISSOR_TEST is enabled.
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).
298 * The state of the face culling (CULL_FACE) enable is ignored.
300 void StencilStrokePathCHROMIUM(uint path, int reference, uint mask)
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.
308 If /path/ does not name an existing path object, the command does
309 nothing (and no error is generated).
311 The path object's specified stroke width (in path space) determines
312 the width of the path's stroked region.
314 The stroke of a transformed path's outline
315 is the region of window space defined by the union of:
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.
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.
326 * Join style regions (explained below) between connected path
327 segments meet.
329 Any accessible samples within the union of these three regions are
330 considered within the path object's stroke.
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.
335 The /mask/ parameter controls what subset of stencil bits are affected
336 by the command.
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.
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.
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.
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
386 sweep = ((1-sab)*sw)/2
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.
395 void CoverFillPathCHROMIUM(uint path, enum coverMode)
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.
408 If /path/ does not name an existing path object, the command does
409 nothing (and no error is generated).
411 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM.
412 Otherwise, INVALID_ENUM error is generated.
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.
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.
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.
436 void CoverStrokePathCHROMIUM(uint path, enum coverMode)
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.
446 If /path/ does not name an existing path object, the command does
447 nothing (and no error is generated).
449 /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM.
450 Otherwise, INVALID_ENUM error is generated.
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.
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.
465 void StencilThenCoverFillPathCHROMIUM(uint path, enum fillMode, uint mask, enum coverMode)
467 The command is equivalent to the two commands
469 StencilFillPathCHROMIUM(path, fillMode, mask);
470 CoverFillPathCHROMIUM(path, coverMode);
472 unless either command would generate an error; for any such error
473 other than OUT_OF_MEMORY, only that error is generated.
475 void StencilThenCoverStrokePathCHROMIUM(uint path, int reference, uint mask, enum coverMode)
477 The command is equivalent to the two commands
479 StencilStrokePathCHROMIUM(path, reference, mask);
480 CoverStrokePathCHROMIUM(path, coverMode);
482 unless either command would generate an error; for any such error
483 other than OUT_OF_MEMORY, only that error is generated.
486 PATH COVERING RASTERIZATION DETAILS
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:
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.
501 Depth offset (section 3.6.2) and polygon multisample rasterization
502 (3.6.3) do apply to path covering.
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.
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).
522 Errors
524 None.
526 New State
528 Get Value Type Get Command Initial Description
529 ----------------------------- ----- ------------ -------- -------------------
530 PATH_MODELVIEW_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current modelview
531 matrix for path rendering
532 PATH_PROJECTION_MATRIX_CHROMIUM 16xR GetFloatv all 0's Current projection
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 read
538 Z+ GetIntegerv 1's mask
540 Tables
541 Table 5.pathCommands: Path Commands
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
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_CHROMIUM
568 PATH_JOIN_STYLE_CHROMIUM enum MITER_REVERT_CHROMIUM, BEVEL_CHROMIUM, ROUND_CHROMIUM
569 PATH_MITER_LIMIT_CHROMIUM float non-negative
570 PATH_STROKE_BOUND_CHROMIUM float will be clamped to [0, 1.0], initially 0.2 (20%)
573 Issues
575 1. Should there be a distinct stencil function state for path
576 stenciling?
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.
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.
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.
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?
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.
600 3. What is the defined behavior when stroking if PATH_STROKE_WIDTH is
601 zero?
603 There will not be any samples within the stroke. I.e. the stroke does
604 not produce any visible results.
606 4. How do you define a program that's valid to use with these calls.
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.
613 5. Can same programs be used to render regular GL primitives as well
614 as in covering paths?
616 Yes.
618 6. How is the fragment shader called when covering paths, and with
619 which values for the inputs?
621 gl_FragCoord: Interpolated coordinate of the path coverage.
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
629 user-defined varyings: constant zeros.
631 Revision History
633 14/8/2014 Documented the extension