Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(88)

Side by Side Diff: gpu/GLES2/extensions/CHROMIUM/CHROMIUM_path_rendering.txt

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

Powered by Google App Engine
This is Rietveld 408576698