1Name 2 3 NV_path_rendering_shared_edge 4 5Name Strings 6 7 GL_NV_path_rendering_shared_edge 8 9Contact 10 11 Mark Kilgard, NVIDIA (mjk 'at' nvidia.com) 12 Jeff Bolz, NVIDIA (jbolz 'at' nvidia.com) 13 14Contributors 15 16 Michael Chock, NVIDIA (mchock 'at' nvidia.com) 17 18Status 19 20 Shipping 21 22Version 23 24 Last Modified Date: March 27, 2015 25 Version: 2 26 27Number 28 29 OpenGL Extension #471 30 OpenGL ES Extension #234 31 32Dependencies 33 34 This extension is written against the OpenGL 4.3 (Compatibility) 35 Specification but can apply to OpenGL 1.1 and OpenGL ES 2.0 and up. 36 37 This extension requires NV_path_rendering. 38 39Overview 40 41 This extension introduces a new path command modifier to the 42 NV_path_rendering extension to indicate that a path command represents an 43 edge (either straight or curved) that is shared with another path. 44 45 When used in conjunction with NV_framebuffer_mixed_samples, a shared edge 46 (or a whole path including shared edges) will use modified rasterization 47 rules in order to ensure that groups of raster samples associated with a 48 given coverage sample will all produce consistent coverage results, in 49 order to avoid artifacts described further in the issues section at the 50 end of this document. 51 52New Procedures and Functions 53 54 None. 55 56New Tokens 57 58 Allowed to be added to command tokens in elements of the <commands> 59 array parameter of PathCommandsNV and PathSubCommandsNV: 60 61 SHARED_EDGE_NV 0xC0 62 63 64Modify Section 5.X "Path Rendering" from the NV_path_rendering extension: 65 66 Add to the end of Section 5.X.1 (Path Specification) 67 68 When the value of SHARED_EDGE_NV is bitwise exclusive-ORed with any of the 69 path command tokens in Table 5.pathCommands (but not the character 70 aliases), the path outline generated by this path command is considered a 71 "shared" version of the original command. When such paths are stenciled 72 (see section 5.X.2.1), coverage for groups of raster samples corresponding 73 to the same color sample must be produce the same result (i.e. must all be 74 covered or all be uncovered) with respect to this particular path command's 75 contour edge. Depending on the implementation, this modified coverage 76 determination may be applied to all edges in a path if that path contains 77 any shared edges. When such paths are covered, groups of raster samples 78 may also be treated the same way (i.e. altering properties of some samples 79 in order to produce the same coverage for all samples in the group). 80 81 82Additions to the AGL/GLX/WGL Specifications 83 84 None 85 86Additions to the OpenGL Shading Language 87 88 None 89 90GLX Protocol 91 92 None 93 94Errors 95 96 None 97 98Issues 99 100 1. What is the GL_SHARED_EDGE_NV value for? 101 102 RESOLVED: Path rendering sometimes requires subregions of two 103 paths to be drawn such that they are "watertight". This means 104 that the color samples along this shared contour should not have 105 any coverage gaps or double hits. 106 107 The problem with mixed sample frequencies is that fractional 108 coverage is computed as a result of the stencil test. A color 109 sample might be 25% covered by one path command edge of path X 110 and then 75% covered by the identical path command edge of path 111 Y such that path X covers the "righthand" side of the color 112 sample and path Y covers the "lefthand" side of the color sample. 113 Such situations can cause an artifact known as "conflation" 114 that allows a background color to "leak through" the edge when 115 the edge is intended by the content creator (often an artist or 116 perhaps a path preprocessing tools) to allow no such leakage. 117 118 Consider the watertight edge when the background color is RED 119 (1,0,0,1), path X's color is GREEN (0,1,0,1), and path Y's 120 color is BLUE (0,0,1,1). If we draw path X first, we get 25% 121 GREEN and 75% RED (the background color) composited into the 122 framebuffer assuming a GL_ONE,GL_ONE_MINUS_SRC_ALPHA blend mode 123 with the GL_RGBA coverage modulation mode. The result is 124 (0.75,0.25,0.0,1.0). Now if we draw path Y first, we get 125 75% BLUE and 25% of (0.75,0.25,0.0,1.0). This result is 126 (0.1875,0.0625,0.75,1). 127 128 However the arguably "correct" watertight result is 129 (0,0.25,0.75,1). The problem is if we process path X and path Y 130 in separate passes, we risk "blending" in some of the background 131 color. The source of this artifact is the assumption that we 132 can translate boolean per-sample coverage into a "fractional" 133 coverage value. 134 135 Note that this situation occurs even when the paths being rendered 136 (X and Y in this example) are 100% opaque. 137 138 At the cost of losing some sub-color sample coverage determination 139 accuracy, we can avoid this artifact by marking as a "shared 140 edge" path commands that are intended to be watertight with 141 edges of the identical path command in another path object. 142 When such commands are encountered, coverage computations done 143 by NV_path_rendering can be careful to decide the coverage of 144 secondary samples with respect to this path edge identically to 145 their respective primary sample. This ensures the coverage (at 146 least with respect to this particular edge) is either 0% or 100%. 147 148 Note that unshared edges from path commands not marked as shared 149 by the addition of the GL_SHARED_EDGE_NV value are processed 150 at the effective raster sample rate. This ensures that edges of 151 the path retain a high level of antialiasing quality. 152 153 This capability is most interesting to path rendering standards 154 such as Flash. 155 156 2. Should the GL_SHARED_EDGE_NV value be bit that can be bitwise 157 ORed into a path command? 158 159 RESOLVED: No. Instead the GL_SHADED_EDGE_NV value of 0xC0 160 (192) should be exclusive-ORed (^) to construct path commands 161 with a shared edge. 162 163 Rationale: The NV_path_rendering assignment of 8-bit token 164 values is arranged to match OpenVG for commands OpenVG supports 165 and numbers the non-OpenVG commands downward from 255 so there is 166 not a bit value to bitwise OR (or even add) that guarantees 167 unique values, particularly considering the character alias values 168 (such as 'C' for GL_CUBIC_CURVE_TO_NV). 169 170 Bitwise exclusive-ORing with 0xC0 does provide unique values 171 for all current (and expected future) path command tokens. 172 173 174 3. The SVG and PostScript path string grammars don't have a way to 175 express shared edges. Is this a problem? 176 177 RESOLVED: No. We support these grammars "as is" from SVG and 178 PostScript. These standards don't really have a way to convey 179 shared edges in paths as Flash shapes allow. 180 181 4. What does GL_MOVE_TO_NV^GL_SHARED_EDGE_NV mean? 182 183 RESOLVED: Bitwise exclusive-ORing GL_SHARED_EDGE_NV works for 184 any legal path token. 185 186 GL_MOVE_TO_NV+GL_SHARED_EDGE_NV means the same as GL_MOVE_TO_NV 187 because the GL_MOVE_TO_NV don't really generate an edge (and 188 likewise for its variant GL_RELATIVE_MOVE_TO_NV). 189 190 Yes, it is legal. 191 192 5. What about 'C'+GL_SHARED_EDGE_NV? Are these allowed? 193 194 RESOLVED: No. 195 196 Character aliases don't support the bitwise exclusive-ORing of 197 GL_SHARED_EDGE_NV. This is to reduce the risk of collisions 198 with character aliases and future path commands. 199 200 201Revision History 202 203 Revision 2, 2015/03/27 204 - Add ES interactions 205 206 Revision 1 207 - Internal revisions. 208