command_buffer: Implement path rendering functions for CHROMIUM_path_rendering

gpu/GLES2/extensions/CHROMIUM/CHROMIUM_path_rendering.txt

 Name
 
     CHROMIUM_path_rendering
 
 Name Strings
 
     GL_CHROMIUM_path_rendering
 
 Version
 
     Last Modifed Date: August 14, 2014
 
 Dependencies
 
     OpenGL ES 3.0 is required.
 
 Overview
 
     This extensions implements path rendering using
     OpenGL API.
 
 New Tokens
 
     Accepted by the <matrixMode> parameter of MatrixLoadfCHROMIUM and
     MatrixLoadIdentityCHROMIUM:
     PATH_MODELVIEW_CHROMIUM                           0x1700
     PATH_PROJECTION_CHROMIUM                          0x1701
 
+    Accepted in elements of the <commands> array parameter of
+    PathCommandsCHROMIUM:
+    CLOSE_PATH_CHROMIUM                               0x00
+    MOVE_TO_CHROMIUM                                  0x02
+    LINE_TO_CHROMIUM                                  0x04
+    QUADRATIC_CURVE_TO_CHROMIUM                       0x0A
+    CUBIC_CURVE_TO_CHROMIUM                           0x0C
+    CONIC_CURVE_TO_CHROMIUM                           0x1A
+
     Accepted by the <pname> parameter of GetIntegerv,
     GetFloatv:
     PATH_MODELVIEW_MATRIX_CHROMIUM                    0x0BA6
     PATH_PROJECTION_MATRIX_CHROMIUM                   0x0BA7
 
+    Accepted by the <pname> parameter of PathParameter{if}CHROMIUM:
+    PATH_STROKE_WIDTH_CHROMIUM                        0x9075
+    PATH_END_CAPS_CHROMIUM                            0x9076
+    PATH_JOIN_STYLE_CHROMIUM                          0x9079
+    PATH_MITER_LIMIT_CHROMIUM                         0x907a
+    PATH_STROKE_BOUND_CHROMIUM                        0x9086
+
+    Accepted by the <value> parameter of PathParameter{if}CHROMIUM:
+    FLAT_CHROMIUM                                     0x1D00
+    SQUARE_CHROMIUM                                   0x90a3
+    ROUND_CHROMIUM                                    0x90a4
+    BEVEL_CHROMIUM                                    0x90A6
+    MITER_REVERT_CHROMIUM                             0x90A7
+
+    Accepted by the <fillMode> parameter of StencilFillPathCHROMIUM:
+    COUNT_UP_CHROMIUM                                 0x9088
+    COUNT_DOWN_CHROMIUM                               0x9089
+
+    Accepted by the <coverMode> parameter of CoverFillPathCHROMIUM,
+    CoverStrokePath, StencilThenCoverFillPathCHROMIUM and
+    StencilThenCoverStrokePathCHROMIUM:
+    CONVEX_HULL_CHROMIUM                              0x908B
+    BOUNDING_BOX_CHROMIUM                             0x908D
+
 
 New Procedures and Functions
 
     void MatrixLoadfCHROMIUM(enum matrixMode, float* matrix)
 
     Takes a pointer to a 4x4 matrix stored in column-major order as 16
     consecutive floating-point values. The matrixMode specifies which
     matrix, PATH_MODELVIEW_CHROMIUM or PATH_PROJECTION_CHROMIUM is used.
 
     The funcition specifies either modelview or projection matrix
     to be used with path rendering API calls.
 
     void MatrixLoadIdentityCHROMIUM(enum matrixMode)
 
     Effectively calls MatrixLoadf with the identity matrix.
 
+    uint GenPathsCHROMIUM(sizei range)
+
+    Returns an integer /n/ such that names /n/, ..., /n+range-1/ are
+    previously unused (i.e. there are /range/ previously unused path object
+    names starting at /n/).  These names are marked as used, for the
+    purposes of subsequent GenPathsCHROMIUM only, but they do not acquire
+    path object state until each particular name is used to specify
+    a path object.
+
+    Returns 0 if no new path name was marked as used. Reasons for this
+    include lack of free path names or range being 0 or a GL error
+    was generated.
+
+    INVALID_VALUE error is generated if range is negative or does not
+    fit in 32-bits.
+
+    void DeletePathsCHROMIUM(uint path, sizei range)
+
+    Deletes a path object where /path/ contains /range/ names of path objects to
+    be delete. After a path object is deleted, its name is again unused.
+    Unused names in /paths/ are silently ignored.
+
+    INVALID_VALUE error is generated if range is negative or does not
+    fit in 32-bits.
+
+    INVALID_VALUE error is generated if the path range would overflow, eg. if
+    path + uint(range) - 1u < path.
+
+    boolean IsPathCHROMIUM(uint path);
+
+    The query returns TRUE if /path/ is the name of a path object.  If path is
+    not the name of a path object, or if an error condition occurs,
+    IsPathCHROMIUM returns FALSE.  A name retuned by GenPathsCHROMIUM, but
+    without a path specified for it yet, is not the name of a path object.
+
+    void PathCommandsCHROMIUM(uint path, sizei numCommands,
+                        const ubyte* commands, sizei numCoords,
+                        enum coordType, const GLvoid* coords)
+
+    Specifies a path object commands for /path/ where /numCommands/
+    indicates the number of path commands, read from the array
+    /commands/, with which to initialize that path's command sequence.
+    The type of the coordinates read from the /coords/ array is
+    determined by the /coordType/ parameter which must be one of BYTE,
+    UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT, or FLOAT, otherwise the
+    INVALID_ENUM error is generated.  These path commands reference
+    coordinates read sequentially from the /coords/ array.
+
+    The /numCommands/ elements of the /commands/ array must be tokens
+    in Table 5.pathCommands.  The command sequence matches
+    the element order of the /commands/ array.  Each command references
+    a number of coordinates specified by "Coordinate count" column of
+    Table 5.pathCommands, starting with the first (zero) element of
+    the /coords/ array and advancing by the coordinate count for each
+    command.  If any of these /numCommands/ command values are not
+    listed in the "Token" column of Table
+    5.pathCommands, the INVALID_ENUM error is generated.
+
+    The INVALID_OPERATION error is generated if /numCoords/ does not
+    equal the number of coordinates referenced by the command sequence
+    specified by /numCommands/ and /commands/ (so /numCoords/ provides a
+    sanity check that the /coords/ array is being interpreted properly).
+    The error INVALID_VALUE is generated if either /numCommands/ or
+    /numCoords/ is negative.
+
+    The error INVALID_OPERATION is generated if /path/ is
+    not an existing path object.
+
+    The error INVALID_VALUE is generated if /numCoords/ or /numCommands/

[piman, 2015/06/24 03:27:44]

nit: that'd typically be an INVALID_OPERATION error case.

[Kimmo Kinnunen, 2015/06/24 12:49:01]

Done.
Though, _typically_, the command buffer uses INVALID_VALUE for the integer
overflow errors. Maybe my wording here misleads that the parameters would be
checked individually. The 32-bit limiting checks indeed are INVALID_OPERATION.

+    are too big for the implementation. This can happen, for example,
+    if some intermedate buffer is created for holding the values, but
+    the buffer length would exceed the maximum the implementation would
+    allow.

[piman, 2015/06/24 03:27:44]

Is there any way to query such limit, or ensure a minimum valid size? Forcing a
round trip on every path creation (to check for error) is very unfortunate.

[Kimmo Kinnunen, 2015/06/24 12:49:01]

Just so that I understand: the problem is that correct parameters might fail due
to implementation details. The expectation of callers would be to implement the
calling code so that the parameters are always correct by spec, and then just
omit the error check. Is this correct interpretation of the problem?

The limit is sizeof(coordType) * num_coords + num_commands not overflowing
32-bit uint. I could write that in the spec?

Though: why is it worry here, but not worry in other functions that have the
similar problem?

PathCommands is sort of similar to BufferData. BufferData, for example,
validates arguments for command buffer limitations and then fails (without the
error documented?). So you can have BufferData call with size == X to succeed
and you can have size == X+1 fail. If I understand correctly from the callers
perspective both should succeed if the first succeeds, and the caller should be
"allowed" to omit the error check.

[piman, 2015/06/24 22:50:18]

Yes, please. If that's the limitation, then it is known statically and the
caller doesn't need to round-trip to the service side. The current wording
suggests that it can fail for arbitrary reasons (from the caller's point of
view) and so the caller has to call GetError which forces a round-trip because
it might fail on the service side.
glBufferData is allowed to fail with GL_OUT_OF_MEMORY, like all gl calls, but
it's not explicitly called in the spec for BufferData (instead mentioned at the
top of the spec that every call can fail with that).

[Kimmo Kinnunen, 2015/06/25 12:13:35]

Actually, I meant the GL_INVALID_OPERATION generated by BufferData due to
implementation-dependent limit on |size|, similar to INVALID_OPERATION generated
by PathCommands due to implementation-dependent limit on |numCoords|. And I
contrasted that it appeared to be problem for PathCommands but not BufferData. 
Anyhow, it's not important.

+
+    If the PathCommandsCHROMIUM command results in an error, the path object
+    named /path/ is not changed; if there is no error, the prior contents
+    of /path/, if /path/ was an existent path object, are lost and the
+    path object name /path/ becomes used.
+
+    void PathParameterfCHROMIUM(uint path, enum pname, float value)
+    void PathParameteriCHROMIUM(uint path, enum pname, int value)
+
+    The commands specify the value of path parameters for the specified path
+    object named /path/.  The error INVALID_OPERATION is generated if /path/ is
+    not an existing path object.
+
+    Each parameter has a single (scalar) value.
+
+    /pname/ must be one of the tokens in the "Name" column of
+    Table 5.pathParameters.
+    The required values or range of each allowed parameter name token
+    is listed in Table 5.pathParameter's "Required Values/Range" column.
+
+    For values of /pname/ listed in Table 5.pathsParameters, the specified
+    parameter is specified by /value/ when /value/ is a float or int,
+    or if /value/ is a pointer to a float or int, accessed through that
+    pointer.  The error INVALID_VALUE is generated if the specified
+    value is negative for parameters required to be non-negative in
+    Table 5.pathParameters.
+
+    The error INVALID_VALUE is generated if the specified parameter value
+    is not within the require range for parameters typed float or integer.
+    The error INVALID_ENUM is generated if the specified parameter value
+    is not one of the listed tokens for parameters typed enum.
+
+    void PathStencilFuncCHROMIUM(enum func, int ref, uint mask)
+
+    Configures the stencil function, stencil reference value, and stencil read
+    mask to be used by the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM
+    commands described subsequently. The parameters accept the same values
+    allowed by the StencilFunc command.
+
+    void StencilFillPathCHROMIUM(uint path, enum fillMode, uint mask)
+
+    The function transforms into window space the outline of the path object
+    named /path/ based on the current modelview, projection and viewport,
+    transforms (ignoring any vertex and/or geometry shader or program that might
+    be active/enabled) and then updates the stencil values of all /accessible
+    samples/ (explained below) in the framebuffer.  Each sample's stencil buffer
+    value is updated based on the winding number of that sample with respect to
+    the transformed outline of the path object with any non-closed subpath
+    forced closed and the specified /fillMode/.
+
+    If /path/ does not name an existing path object, the command does
+    nothing (and no error is generated).
+
+    If the path's command sequence specifies unclosed subpaths (so not
+    contours) due to MOVE_TO_CHROMIUM commands, such subpaths are trivially
+    closed by connecting with a line segment the initial and terminal
+    control points of each such path command subsequence.
+
+    Transformation of a path's outline works by taking all positions on the
+    path's outline in 2D path space (x,y) and constructing an object space
+    position (x,y,0,1) that is then used similar to as with the (xo,yo,zo,wo)
+    position in section 2.12 ("Fixed-Function Vertex Transformation") of OpenGL
+    3.2 (unabridged) Specification (Special Functions) to compute corresponding
+    eye-space coordinates (xe,ye,ze,we) and clip-space coordinates
+    (xc,yc,zc,wc).  A path outline's clip-space coordinates are further
+    transformed into window space similar to as described in section 2.16
+    ("Coordinate Transformations").  This process provides a mapping 2D path
+    coordinates to 2D window coordinates.  The resulting 2D window coordinates
+    are undefined if any of the transformations involved are singular or may be
+    inaccurate if any of the transformations (or their combination) are
+    ill-conditioned.
+
+    The winding number for a sample with respect to the path outline,
+    transformed into window space, is computed by counting the (signed)
+    number of revolutions around the sample point when traversing each
+    (trivially closed if necessary) contour once in the transformed path.
+    This traversal is performed in the order of the path's command
+    sequence.  Starting from an initially zero winding count, each
+    counterclockwise revolution when the front face mode is CCW (or
+    clockwise revolution when the front face mode is CW) around the sample
+    point increments the winding count by one; while each clockwise
+    revolution when the front face mode is CCW (or counterclockwise
+    revolution when the front face mode is CW) around the sample point
+    decrements the winding count by one.
+
+    The /mask/ parameter controls what subset of stencil bits are affected
+    by the command.
+
+    The /fillMode/ parameter must be one of INVERT, COUNT_UP_CHROMIUM
+    or COUNT_DOWN_CHROMIUM; otherwise the INVALID_ENUM error
+    is generated.  INVERT inverts the bits set in the effective /mask/
+    value for each sample's stencil value if the winding number for the
+    given sample is odd.  COUNT_UP_CHROMIUM adds with modulo n arithmetic the
+    winding number of each sample with the sample's prior stencil buffer
+    value; the result of this addition is written into the sample's
+    stencil value but the bits of the stencil value not set in the
+    effective /mask/ value are left unchanged.  COUNT_DOWN_CHROMIUM subtracts
+    with modulo /n/ arithmetic the winding number of each sample with the
+    sample's prior stencil buffer value; the result of this subtraction is
+    written into the sample's stencil value but the bits of the stencil
+    value not set in the effective /mask/ value are left unchanged.
+
+    The value of /n/ for the modulo /n/ arithmetic used by COUNT_UP_CHROMIUM
+    and COUNT_DOWN_CHROMIUM is the effective /mask/+1.  The error INVALID_VALUE
+    is generated if /fillMode/ is COUNT_UP_CHROMIUM or COUNT_DOWN_CHROMIUM and
+    the effective /mask/+1 is not an integer power of two.
+
+    ACCESSIBLE SAMPLES WITH RESPECT TO A TRANSFORMED PATH
+
+    The accessible samples of a transformed path that are updated are
+    the samples that remain after discarding the following samples:
+
+        *   Any sample that would be clipped similar to as specified in section
+            2.22 ("Primitive Clipping") of OpenGL 3.2 (unabridged) Specification
+            (Special Functions) because its corresponding position in clip space
+            (xc,yc,zc,wc) or (xe,ye,ze,we) would be clipped by the clip volume
+            or enabled client-defined clip planes.
+
+        *   Any sample that would fail the pixel ownership test (section
+            4.1.1) if rasterized.
+
+        *   Any sample that would fail the scissor test (section 4.1.2)
+            if SCISSOR_TEST is enabled.
+
+    And for the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM commands
+    (so not applicable to the CoverFillPathCHROMIUM and CoverStrokePathCHROMIUM
+    commands):
+        *   Any sample that would fail the (implicitly enabled) stencil test
+            with the stencil function configured based on the path stencil
+            function state configured by PathStencilFuncCHROMIUM.  In the case
+            of the StencilFillPathCHROMIUM and StencilStrokePathCHROMIUM
+            commands, the effective stencil read
+            mask for the stencil mask is treated as the value of
+            PATH_STENCIL_VALUE_MASK bit-wise ANDed with the bit-invert of the
+            effective /mask/ parameter value; otherwise, for the cover commands,
+            the stencil test operates normally.  In the case the stencil test
+            fails during a path stencil operation, the stencil fail operation is
+            ignored and the pixel's stencil value is left undisturbed (as if the
+            stencil operation was KEEP).
+
+        *   The state of the face culling (CULL_FACE) enable is ignored.
+
+    void StencilStrokePathCHROMIUM(uint path, int reference, uint mask)
+
+    Transforms into window space the stroked region of the path object named
+    /path/ based on the current modelview, projection and viewport transforms
+    (ignoring any vertex and/or geometry shader or program that might be
+    active/enabled) and then updates the stencil values of a subset of the
+    accessible samples (see above) in the framebuffer.
+
+    If /path/ does not name an existing path object, the command does
+    nothing (and no error is generated).
+
+    The path object's specified stroke width (in path space) determines
+    the width of the path's stroked region.
+
+    The stroke of a transformed path's outline
+    is the region of window space defined by the union of:
+
+        *   Sweeping an orthogonal centered line segment of the (above
+            determined) effective stroke width along each path segment
+            in the path's transformed outline.
+
+        *   End cap regions (explained below) appended to the initial
+            and terminal control points of non-closed command sequences
+            in the path.  For a sequence of commands that form a closed
+            contour, the end cap regions are ignored.
+
+        *   Join style regions (explained below) between connected path
+            segments meet.
+
+    Any accessible samples within the union of these three regions are
+    considered within the path object's stroke.
+
+    If the stroke width is zero, each of the regions in the union will
+    be empty and there are no accessible samples within the stroke.
+
+    The /mask/ parameter controls what subset of stencil bits are affected
+    by the command.
+
+    A sample's stencil bits that are set in the effective /mask/ value
+    are updated with the specified stencil /reference/ value if the
+    sample is accessible (as specified above) and within the stroke of
+    the transformed path's outline.
+
+    Every path object has an end caps parameter
+    PATH_END_CAPS_CHROMIUM) that is one of FLAT_CHROMIUM,
+    SQUARE_CHROMIUM or ROUND_CHROMIUM. This parameter defines the
+    initial and terminal caps type. There are no samples within a
+    FLAT_CHROMIUM cap.  The SQUARE_CHROMIUM cap extends centered and
+    tangent to the given end (initial or terminal) of the subpath for
+    half the effective stroke width; in other words, a square cap is a
+    half-square that kisses watertightly the end of a subpath.  The
+    ROUND_CHROMIUM cap appends a semi-circle, centered and tangent,
+    with the diameter of the effective stroke width to the given end
+    (initial or terminal) of the subpath; in other words, a round cap
+    is a semi-circle that kisses watertightly the end of a subpath.
+
+    Every path object has a join style that is one of BEVEL_CHROMIUM,
+    ROUND_CHROMIUM or MITER_REVERT_CHROMIUM.  Each path object also has a miter
+    limit value.  The BEVEL_CHROMIUM join style inserts a triangle with two
+    vertices at the outside corners where two connected path segments join and a
+    third vertex at the common end point shared by the two path segments.  The
+    ROUND_CHROMIUM join style inserts a wedge-shaped portion of a circle
+    centered at the common end point shared by the two path segments; the radius
+    of the circle is half the effective stroke width. The MITER_REVERT_CHROMIUM
+    join style inserts a quadrilateral with two opposite vertices at the outside
+    corners where the two connected path segments join and two opposite vertices
+    with one on the path's junction between the two joining path segments and
+    the other at the common end point shared by the two path segments.  However,
+    the MITER_REVERT_CHROMIUM join style behaves as the BEVEL_CHROMIUM style if
+    the sine of half the angle between the two joined segments is less than the
+    path object's PATH_STROKE_WIDTH value divided by the path's
+    PATH_MITER_LIMIT_CHROMIUM value.
+
+    Every path object has a stroke approximation bound parameter
+    (PATH_STROKE_BOUND_CHROMIUM) that is a floating-point value /sab/ clamped
+    between 0.0 and 1.0 and set and queried with the PATH_STROKE_BOUND_CHROMIUM
+    path parameter.  Exact determination of samples swept an orthogonal
+    centered line segment along cubic Bezier segments and rational
+    quadratic Bezier curves (so non-circular partial elliptical arcs) is
+    intractable for real-time rendering so an approximation is required;
+    /sab/ intuitively bounds the approximation error as a percentage of
+    the path object's stroke width.  Specifically, this path parameter
+    requests the implementation to stencil any samples within /sweep/
+    object space units of the exact sweep of the path's cubic Bezier
+    segments or partial elliptical arcs to be sampled by the stroke where
+
+      sweep = ((1-sab)*sw)/2
+
+    where /sw/ is the path object's stroke width.  The initial value
+    of /sab/ when a path is created is 0.2.  In practical terms, this
+    initial value means the stencil sample positions coverage within 80%
+    (100%-20%) of the stroke width of cubic and rational quadratic stroke
+    segments should be sampled.
+
+
+    void CoverFillPathCHROMIUM(uint path, enum coverMode)
+
+    The command transforms into window space the outline of the path object
+    named /path/ based on the current modelview, projection and viewport
+    transforms (ignoring any vertex and/or geometry shader or program that might
+    be active/enabled) and rasterizes a subset of the accessible samples in the
+    framebuffer guaranteed to include all samples that would have a net
+    stencil value change if StencilFillPathCHROMIUM were issued with the same
+    modelview, projection, and viewport state.  During this rasterization, the
+    stencil test operates normally and as configured; the expectation is the
+    stencil test will be used to discard samples not determined "covered" by a
+    prior StencilFillPathCHROMIUM command.
+
+    If /path/ does not name an existing path object, the command does
+    nothing (and no error is generated).
+
+    /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM.
+    Otherwise, INVALID_ENUM error is generated.
+
+    The subset of accessible pixels that are rasterized are within a bounding
+    box (expected to be reasonably tight) surrounding all the samples guaranteed
+    to be rasterized by CoverFillPathCHROMIUM.  The bounding box must be
+    orthogonally aligned to the path space coordinate system.  (The area of the
+    bounding box in path space is guaranteed to be greater than or equal the
+    area of the convex hull in path space.) Each rasterized sample will be
+    rasterized once and exactly once.
+
+    While samples with a net stencil change /must/ be rasterized,
+    implementations are explicitly allowed to vary in the rasterization
+    of samples for which StencilFillPathCHROMIUM would /not/ change sample's
+    net stencil value.  This means implementations are allowed to (and,
+    in fact, are expected to) conservatively "exceed" the region strictly
+    stenciled by the path object.
+
+    CoverFillPathCHROMIUM /requires/ the following rasterization invariance:
+    calling CoverFillPathCHROMIUM for the same (unchanged) path object with
+    fixed (unchanged) modelview, projection, and viewport transform state
+    with the same (unchanged) set of accessible samples will rasterize
+    the exact same set of samples with identical interpolated values
+    for respective fragment/sample locations.
+
+    void CoverStrokePathCHROMIUM(uint path, enum coverMode)
+
+    The command operates in the same manner as CoverFillPathCHROMIUM except the
+    region guaranteed to be rasterized is, rather than the region within
+    /path/'s filled outline, instead the region within the /path/'s stroked
+    region as determined by StencilStrokePathCHROMIUM.  During this
+    rasterization, the stencil test operates normally and as configured; the
+    expectation is the stencil test will be used to discard samples not
+    determined "covered" by a prior StencilStrokePathCHROMIUM command.
+
+    If /path/ does not name an existing path object, the command does
+    nothing (and no error is generated).
+
+    /coverMode/ must be one of CONVEX_HULL_CHROMIUM or BOUNDING_BOX_CHROMIUM.
+    Otherwise, INVALID_ENUM error is generated.
+
+    Analogous to the rasterization guarantee of CoverFillPathCHROMIUM with
+    respect to StencilFillPathCHROMIUM, CoverStrokePathCHROMIUM guarantees that
+    all samples rasterized by StencilStrokePathCHROMIUM, given the same
+    transforms and accessible pixels and stroke width, will also be rasterized
+    by the corresponding CoverStrokePathCHROMIUM.
+
+    CoverStrokePathCHROMIUM /requires/ the following rasterization invariance:
+    calling CoverStrokePathCHROMIUM for the same (unchanged) path object with
+    fixed (unchanged) modelview, projection, and viewport transform state and
+    with the same (unchanged) set of accessible samples will rasterize the exact
+    same set of samples with identical interpolated values for respective
+    fragment/sample locations.
+
+    void StencilThenCoverFillPathCHROMIUM(uint path, enum fillMode, uint mask, enum coverMode)
+
+    The command is equivalent to the two commands
+
+        StencilFillPathCHROMIUM(path, fillMode, mask);
+        CoverFillPathCHROMIUM(path, coverMode);
+
+    unless either command would generate an error; for any such error
+    other than OUT_OF_MEMORY, only that error is generated.
+
+    void StencilThenCoverStrokePathCHROMIUM(uint path, int reference, uint mask, enum coverMode)
+
+    The command is equivalent to the two commands
+
+        StencilStrokePathCHROMIUM(path, reference, mask);
+        CoverStrokePathCHROMIUM(path, coverMode);
+
+    unless either command would generate an error; for any such error
+    other than OUT_OF_MEMORY, only that error is generated.
+
+
 Errors
 
     None.
 
 New State
 
     Get Value                       Type   Get Command  Initial  Description
     -----------------------------  -----  ------------ -------- -------------------
     PATH_MODELVIEW_MATRIX_CHROMIUM  16xR   GetFloatv    all 0's  Current modelview
                                                                  matrix for path rendering
     PATH_PROJECTION_MATRIX_CHROMIUM 16xR   GetFloatv    all 0's  Current projection
                                                                  matrix for path rendering
+    PATH_STENCIL_FUNC_CHROMIUM      Z8     GetIntegerv  ALWAYS   path stenciling function
+    PATH_STENCIL_REF_CHROMIUM       Z+     GetIntegerv  0        path stenciling
+                                                                 reference value
+    PATH_STENCIL_VALUE_MASK_CHROMIUM                             path stencil read
+                                    Z+     GetIntegerv  1's      mask
+
+Tables
+    Table 5.pathCommands: Path Commands
+
+                                                       Coordinate
+    Token                       Description            count
+    ==========================  =====================  ==========
+    MOVE_TO_CHROMIUM            Absolute move          2
+                                current point
+    --------------------------  ---------------------  ----------
+    CLOSE_PATH_CHROMIUM         Close path             0
+    --------------------------  ---------------------  ----------
+    LINE_TO_CHROMIUM            Absolute line          2
+    --------------------------  ---------------------  ----------
+    QUADRATIC_CURVE_TO_CHROMIUM Absolute quadratic     4
+    --------------------------  ---------------------  ----------
+    CUBIC_CURVE_TO_CHROMIUM     Absolute cubic         6
+                                Bezier segment
+    --------------------------  ---------------------  ----------
+    CONIC_CURVE_TO_CHROMIUM     Absolute conic         5
+                                (rational Bezier)
+                                segment
+
+
+    Table 5.pathParameters
+    Name                             Type     Required Values or Range
+    -------------------------------  -------  -----------------------------------------------
+    PATH_STROKE_WIDTH_CHROMIUM       float    non-negative
+    PATH_END_CAPS_CHROMIUM           enum     FLAT, SQUARE_CHROMIUM, ROUND_CHROMIUM
+    PATH_JOIN_STYLE_CHROMIUM         enum     MITER_REVERT_CHROMIUM, BEVEL_CHROMIUM, ROUND_CHROMIUM
+    PATH_MITER_LIMIT_CHROMIUM        float    non-negative
+    PATH_STROKE_BOUND_CHROMIUM       float    will be clamped to [0, 1.0], initially 0.2 (20%)
+
+
+Issues
+
+   1.   Should there be a distinct stencil function state for path
+        stenciling?
+
+        RESOLVED:  YES.  glPathStencilFunc sets the state.  How the
+        stencil state needs to be configured for path covering is
+        different than how the stencil function is configured typically
+        for path stenciling.
+
+        For example, stencil covering might use
+        StencilFunc(NOT_EQUAL,0,~0) while path stenciling would
+        use ALWAYS for the path stenciling stencil test.
+
+        However there are other situations such as path clipping where it
+        is useful to have the path stencil function configured differently
+        such as PathStencilFunc(NOT_EQUAL, 0x00, 0x80) or other
+        similar path clipping test.
+
+   2.   Since my Cover*Path* skips the vertex shader, what does it mean exactly
+        wrt a fully linked program? What happens to the fragment shader's input
+        varyings that are not filled by the vertex shader + rasterizer?
+
+        It is possible that input varyings from a shader may not be written
+        as output varyings of a preceding shader.  In this case, the unwritten
+        input varying values are undefined. Implementations are encouraged to
+        zero these undefined input varying values.

[piman, 2015/06/24 03:27:44]

I'm not sure what that means... a program fails to link if the fragment shader
uses varyings that don't exist in the vertex shader (see 4.3.5 Varying in GLSL
ES spec
https://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
). If there's no vertex shader, does it mean you must have no input varying in
the fragment shader?

[Kimmo Kinnunen, 2015/06/24 12:49:01]

I think the spec is written in the way that it does not explicitly say that
there is no vertex shader. E.g. linking rules and such are agnostic to this, if
I read this correctly.

It says that vertex shader is *skipped* when Cover function is run. Then
somebody might point out that vertex shader fills the fragment shader varyings,
and then ask that what fills the varyings if vertex shader is skipped. This
answer is an answer to this question.

[piman, 2015/06/24 22:50:18]

Well... there's a lot more than the vertex shader that is skipped by these
calls, and it's not very explicit. Varyings don't come straight from the vertex
shader anyway (clipping, interpolation etc.). So I think we have to be a little
bit more precise than that. I guess there's 2 parts:

1- How do you define a program that's valid to use with these calls. It sounds
like you need a program with a vertex and a fragment shaders, that are well
defined with respect to each other (with the same linking rules) as if the
program was going to be used on regular GL primitives, even though the vertex
shader will never be called - that's fairly awkward, at least should be called
out?
2- How is the fragment shader called, and with which values for the inputs, both
built-in (gl_FragCoord, gl_FrontFacing) and user-defined. It sounds like you
want to leave the user-defined inputs undefined? Can you mention that
explicitly?

[Kimmo Kinnunen, 2015/06/25 12:13:35]

I tried to address these in the .txt by adding a hunk related to path covering
rasterization details as well as few related question-answer pairs. I'm no gl
spec writer, though, so..

I also changed to specify that user-defined inputs would be forced zero. I hope
it's ok, and we can trust that current driver zeroes them and we do not need to
check that in the service side?

+
+   3.   What is the defined behavior when stroking if PATH_STROKE_WIDTH is
+        zero?
+
+        There will not be any samples within the stroke. I.e. the stroke does
+        not produce any visible results.
 
 Revision History
 
     14/8/2014    Documented the extension