3 ms·

Is there no built in GPU path draw command? Seems like it would be similar (although not identical) to what the GPU does for vertices visibility. Especially w

by jayd16 4y ago

Is there no built in GPU path draw command? Seems like it would be similar (although not identical) to what the GPU does for vertices visibility. Especially when you consider what tile based renderers do for determining whether a triangle fully covers a tile (allowing rejection of any other draw onto that tile) it seems like GPUs could have built in support for 'inside a path or outside a path.' Even just approximating with triangles as a pre-pass seems faster than the row based method in the post. Are arbitrary paths just too complex for this kind of optimization?

pyrolistical 4y ago
Depends on your definition of a path. If what you mean is something like a SVG path, then consider the path is defined as a series of command that describe the shape. See https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Pa... From my understanding there is no closed form solution to arbitrary paths defined in that way. So the only way to figure out what the shape looks like, and to figure out if a point is inside or outside, you would need to run all the commands that form the path.
- Lichtso 4y ago
  Meet "Wavelet Rasterization" by J. Manson and S. Schaefer, from the paper: > Because we evaluate wavelet coefficients through line integrals in 2D, we are able to derive analytic solutions for polygons that have Bézier curve boundaries of any order, and we provide solutions for quadratic and cubic curves.
moonchild 4y ago
NV_path_rendering https://developer.nvidia.com/nv-path-rendering https://developer.nvidia.com/nv-path-rendering
interroboink 4y ago
> ... seems faster than the row based method in the post. But the row-based method in the post is not what they describe doing on the GPU version of the algorithm. The row-based method is their initial CPU-style version. The GPU version handles each pixel in isolation, checking it against the relevant shape(s). At least, if I understand things correctly (: As far as I can tell, the approach described here is probably similar to what a built-in "draw path" command would do. Checking if something is inside a triangle is just extremely easy (no concavity, for instance) and common, and more complex operations are left up to shader developers — why burn that special-case stuff into silicon?

by jayd16 4y ago

pyrolistical 4y ago

Depends on your definition of a path. If what you mean is something like a SVG path, then consider the path is defined as a series of command that describe the shape. See https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Pa... From my understanding there is no closed form solution to arbitrary paths defined in that way. So the only way to figure out what the shape looks like, and to figure out if a point is inside or outside, you would need to run all the commands that form the path.

Lichtso 4y ago
Meet "Wavelet Rasterization" by J. Manson and S. Schaefer, from the paper: > Because we evaluate wavelet coefficients through line integrals in 2D, we are able to derive analytic solutions for polygons that have Bézier curve boundaries of any order, and we provide solutions for quadratic and cubic curves.

moonchild 4y ago

NV_path_rendering https://developer.nvidia.com/nv-path-rendering https://developer.nvidia.com/nv-path-rendering

interroboink 4y ago

> ... seems faster than the row based method in the post. But the row-based method in the post is not what they describe doing on the GPU version of the algorithm. The row-based method is their initial CPU-style version. The GPU version handles each pixel in isolation, checking it against the relevant shape(s). At least, if I understand things correctly (: As far as I can tell, the approach described here is probably similar to what a built-in "draw path" command would do. Checking if something is inside a triangle is just extremely easy (no concavity, for instance) and common, and more complex operations are left up to shader developers — why burn that special-case stuff into silicon?