CN113052939A

CN113052939A - Unified coding of patch sections, tops and connections for path delineation

Info

Publication number: CN113052939A
Application number: CN202011448643.4A
Authority: CN
Inventors: M·基尔加德
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2019-12-10
Filing date: 2020-12-09
Publication date: 2021-06-29
Anticipated expiration: 2040-12-09
Also published as: CN113052939B

Abstract

Uniform coding of patch sections, tops, and connections for path edges is disclosed. The present disclosure provides a method of encoding a path, a stroking system for a path, a renderer that generates a stroking tessellation of a path, and a method of determining a link type of a path from a data structure. The data structure may be an array of index links of the compact encoding path. The location of one or more index values (e.g., null index values) within an indexed link may encode the type of link. In one example, an encoding method includes: (1) receiving a path having a plurality of links, wherein the links include at least one section and at least one junction; and (2) generating an encoded path by encoding the links based on the positional information of the links, wherein the encoding employs the same data structure for each link.

Description

Unified coding of patch sections, tops and connections for path delineation

Cross Reference to Related Applications

This application is a continuation-in-part application entitled "POLAR delineation FOR VECTOR GRAPHICS" U.S. application serial No. 16/714,621 filed on 13.12.2019 by Mark Kilgard (POLAR locking FOR VECTOR GRAPHICS ", filed on 10.12.2019, priority of the" U.S. provisional application serial No. 62/946,267 filed on 12.12.2019, which is commonly assigned with the present application and is incorporated herein by reference in its entirety.

Technical Field

The present application relates generally to representing paths including segments and junctions, and more particularly to encoding paths.

Background

Vector graphics (as used in PostScript, PDF, scalable vector graphics, OpenVG, Flash, etc.) render shapes and text in one of two ways: fill (essentially "coloring within the shape") or stroking (essentially "outlining the shape"). These shapes are commonly referred to as "paths", and the process of rendering a filled or stroked path is commonly referred to as "path rendering".

Existing methods perform the stroking by slower CPU rasterization techniques or faster GPU methods that involve extensive CPU preprocessing. The need for CPU-based preprocessing often places the GPU stroking approach under the constraints of CPU operation. Furthermore, CPU-based pre-processing for GPU stroking methods typically combines rendering states (e.g., the stroking width, the top (cap) pattern, and the join (join) pattern) into a GPU representation of a path, which becomes expensive to alter, e.g., by re-tessellating. Such a GPU representation takes up much more memory than the original representation of the path.

Disclosure of Invention

In one aspect, the present disclosure provides a method of encoding a path. In one example, the method includes: (1) receiving a path having a plurality of links, wherein the link includes at least one segment and at least one junction; and (2) generating an encoded link by encoding the link based on the positional information of the link, wherein the encoding employs the same data structure for each link.

In another aspect, the present disclosure provides a system for tracing a path. In one example, the stroking system includes: (1) a path processor configured to decompose a path into links and encode the links, wherein the links comprise at least one section and at least one junction point, wherein the path processor is configured to encode the path using the same data structure for each link; and (2) a stroking processor configured to subdivide the encoded path surface into geometric primitives corresponding to stroked regions of the path.

In yet another aspect, the present disclosure provides a renderer. In one example, a renderer includes: (1) a first processor configured to decompose a path into links and encode the links as indexed links, wherein the links comprise one or more sections and one or more junction points; and (2) a second processor configured to represent a stroked tessellation of the generation path based on the polar stroked of each link using the indexed links.

In yet another aspect, the present disclosure provides a method of determining a type of link of a path from a data structure. In one example, the method of determining the type of link includes: (1) analyzing a data structure encoding a link, the data structure having a plurality of indices related to an array of control point coordinates corresponding to the link; and (2) determining a type of the link based on a presence of at least one index null value for at least one of the indexes.

In yet another aspect, the present disclosure provides a method of encoding a path that includes a plurality of segments and a plurality of junctions connecting each successive pair of adjacent segments. In one example, the encoding method includes: (1) for each segment, and using the same representation format for each segment, encoding the segment as a first indexed link; and (2) for each splice point, and using the same representation format, encoding the splice point as a second indexed link. Each section is a cubic bezier section, a quadratic bezier section, a cone section, or a line segment, each junction is a vertex or a connection, and the first indexed link and the second indexed link comprise a field whose value indicates whether the section or junction is encoded in a given instance.

Brief description of the drawings

Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows a diagram of an example of a path having at least one section that may be encoded and at least one junction in accordance with the principles of the present disclosure;

FIG. 2 illustrates a block diagram of an example of a stroking system configured as an encoding path in accordance with the principles of the present disclosure;

FIG. 3 illustrates a block diagram of an example of a renderer configured to perform path encoding in accordance with the principles of the present disclosure;

FIG. 4 illustrates a block diagram of another example of a renderer configured to perform path encoding in accordance with the principles of the present disclosure;

FIG. 5 illustrates a flow chart of an example of a method of polar-coordinate stroking using an encoded path constructed in accordance with the principles of the present disclosure;

FIGS. 6, 7, 8 and 9 illustrate examples of encoding of a path segment and its indexed links constructed in accordance with the principles of the present disclosure;

10-14 illustrate examples of different links from the paths and encoding paths of FIG. 1 in accordance with the principles of the present disclosure;

FIG. 15 illustrates an example of encoding of the full path of FIG. 1 constructed in accordance with the principles of the present disclosure;

FIG. 16 illustrates a flow chart of an example of determining a type of link from indexed links, performed in accordance with the principles of the present disclosure;

FIG. 17 illustrates a block diagram of an example of a computing device configured to display a path using polar tracing in accordance with the principles of the present disclosure; and

FIG. 18 illustrates a block diagram of an example of a printer configured to utilize a stroked print path in accordance with the principles of the present disclosure.

Detailed Description

The present disclosure provides improvements for encoding paths that unify path segments and path junctions. The present disclosure employs indexed link coding to provide a unified compact representation for both path segments and path junctions. The compact representation is well suited for GPU access and GPU tessellation using, for example, a mesh shader. The compact representation is a data structure with memory efficient coding that uses indices to deduplicate redundant control points of a path. The data structure can be quickly constructed using the position information of the sections and joints without the need for recursive processing. In addition, the data structure may defer (defer) mapping from the position top and connection type to the geometry top and connection type until rendering. Thus, flexible rendering is provided in the case where the process of changing the stroke width, the top style, or the connection style is relatively inexpensive.

A path, as used herein, is a sequence of zero or more path components, referred to herein as links. The links of the path are specified by an ordered set of control points and may be path segments or path junction points. A path segment is a link that specifies a stroked path segment from its first control point to its last control point. A path junction point is a link that connects two segments in sequence or that starts or ends a path segment without connecting to any segment. A junction is a link connecting two path segments. A non-connecting junction is a link of a segment that is not connected to other segments. Connection joints are also called connections (joins); the non-connecting junction is also referred to as a tip (cap).

Linking advantageously provides a uniform way to handle sections, tops, and connections, which is also well suited for parallel processing (e.g., by a GPU). As described above, the link has control points, and the generative curve (also referred to herein as the generative equation) is a parametric curve specified by the control points of the link. A control point is a determined two-dimensional (2D) location, designated as either an (x, y)2D coordinate pair or an (x, y, w) rational 2D coordinate triplet for a cone (rational) bezier path segment. There are two types of control points, interpolated control points and extrapolated control points. Interpolated control points are control points comprised by a section or a junction point and extrapolated control points are control points establishing the gradient direction of the section or the junction point.

A path may include various arrangements of different links connected together. One example is a closed-linked sequence, which is a sequence in which the initial control point of the initial link and the end control point of the end link are in the same position and share a connected segment that connects the junction points. Thus, the closed linked sequence lacks a path top. An open-linked sequence is another example, which is a sequence of linked segments in which the initial control points of the initial segment links and the end control points of the end segment links do not share a connection connecting junction points. Closed-loop sequences are also called contours (contours) and open-linked sequences are also called tracks. Unlike closed-linked sequences, open-linked sequences have a path top. The top of the path is a non-connecting link that marks the beginning or end of the sequence of connecting links for the path. More specifically, the initial path top is a link that begins the open sequence of linked segments, and the end path top is a link that ends the open linked sequence of linked segments.

The present disclosure provides a method and system for encoding a path that uniformly encodes links regardless of whether the links are sections or junctions. The disclosed linking encoding uses the same data structure, i.e., linking structure, to encode the sections and junctions of the path. The data structure includes the necessary location information for the links in a compact format that allows efficient decoding of the strokes. The location information may be coordinate values of the link or may be references to coordinate values. In addition to being compact, the data structure is also structured to provide an efficient parallel tessellation (and subsequent rasterization) process for the GPU. The GPU is designed to efficiently process indexed vertex data and therefore can efficiently process the disclosed compact data structures.

The data structure for compactly encoding the path may be an indexed linked array (array) that specifies a control point for each link by a control point index to the control point coordinate array of the path. The control point coordinate array is an array including the control point coordinates of the encoding path. Each indexed link is a data structure corresponding to an individual link for which the link specifies a control point as an index of the control point in the array of control point coordinates to the encoding path. An index value, referred to as a null index value, is a special index value that is designated to indicate an unnecessary control point. The null index value may be zero. The location of one or more null index values in the indexed link will encode the type of link. The control point coordinate array includes at least one null value, and the indexed link indicates a link type based on the presence or absence of one or more null index values corresponding to the null value.

As described above, the data structure may be compact. For example, indexed links may have an 8-bit or 16-bit index to represent a shared interpolation control point that is "shared" by one or two sections or splice points. In this way, the encoded representations of the links and the paths they form can be stored without requiring a large amount of memory. The index in the indexed link may be as small as six unsigned bytes (any path with 255 or fewer control points can be processed). In practice, this number of control points is sufficient for most paths of glyphs, simple logos, rounded rectangles, and other basic shapes. When a control point is typically two 32-bit floating point values (8 bytes), the small link size of six bytes is smaller than a single control point. For paths with more than 255 control points, 16-bit indices or even 32-bit indices can be used and still maintain a compact structure.

Indexing as disclosed herein also allows control points to be stored once and indexed several times. Considering that the standard case of a path is a sequence of connected cubic bezier segments, each cubic segment may have three new control points (24 ═ 3 × 8 bytes) because each segment "shares" its initial control point with the end control point of the previous segment. Furthermore, the connection junction (connection) between each pair of connected path segments does not require an additional control point, but may index control points from the two path segments it is connecting. This compactness is beneficial when drawing detailed graphics (e.g., a street map of an entire city, especially when there are sewer pipes, gas pipes, electronic pipes, etc.). Another example of a complex pattern is a Printed Circuit Board (PCB) or chip layout.

Another advantage due to the compact data structure is that the control point coordinate array will typically be floating point x and y values (four bytes per coordinate, eight bytes per point), but may also be a 16-bit signed integer value (2 bytes per coordinate, 4 bytes per point). Thus, the size of the control point coordinate array can be halved. Further, the path encoded as a 16-bit integer using control points may be converted as part of the rendering (tessellation and rasterization) process to stretch/translate/project the path into any alternate coordinate space. Advantageously, glyphs in the standard TrueType font file format are stored as 16-bit signed integer values that allow path rendering of matching fonts. In some examples, 8-bit coordinates may be stored if required by the various formats.

The stroking path tessellation process also demonstrates the compactness advantages of the disclosed data structure. For example, a quadrilateral sequence may be generated during the stroking path tessellation process. For a curved link, the link may be subdivided by the surface into tens or hundreds of quadrilaterals. Storing the tessellation requires more memory than storing the data structures (e.g., indexed links) that generate the tessellation. Even if the line segments are stored with the connections between each connected segment. The quadrilateral of each line segment will still need to be stored. This means that four 2D points are stored compared to only one, since each line segment actually only adds one new control point. Connections that require additional control points must also be handled; especially for circular connections.

As described above, the data structure allows for efficient decoding of the stroke. The stroke may be a polar stroke that steps at a tangent angle with links (both segments and joints) along the path to provide a polar stroke representation of the path. Stepping along the path at tangent angles involves "solving" to determine when a link is likely to change from a clockwise turn to a counterclockwise turn (or vice versa), and then solving in each step when the gradient of the link is perpendicular to the 90 degree rotation of each tangent angle step. This method may use trigonometric functions and solve for line-curve intersections in each step along the path.

Polar delineation represents a delineation tessellation (tessellation) that may be used to generate a path. For example, the polar stroked representation of a link may be a sequence of polygons (e.g., quadrilaterals) representing the link, and may be used to generate a stroked tessellation. For existing methods of generating a stroked tessellation using a CPU, stepping of the tangent angle would be an expensive method. An efficient trigonometric function evaluation (sin, cos, atan2) of a parallel processor such as a GPU makes a solution step stepping at tangent angles fully feasible. For example, because the polar-stroking method determines how many steps to take without recursive processing, the polar-stroking method may map well to GPU tessellations and mesh shaders. The entire polar-based delineation method (e.g., tessellation, rasterization, and shading) may be performed by the GPU.

The disclosed polar-coordinate delineation may be used to improve the performance and quality of delineation path rendering in several different domains including web browsers (scalable vector graphics (SVG)), document viewers (PDF), navigation and mapping systems, and illustration applications (Adobe Illustrator, Inkscape). Polar delineation may also be used to control different machines that perform operations according to an input path. Such as a Computer Numerical Control (CNC) machine that processes the material according to an input path. Polar tracing is also useful where the tracing expansion occurs in a different coordinate space than the path itself. A typical use is window space delineation (referred to as non-scaling delineation in SVG). This is advantageous for applications such as maps and navigation systems where the stroke is specified in width in pixels (typically 1) so that the width of the grid line or marker does not scale as well when zooming into the map. As with the disclosed encoding, the polar tracing method may also process each link of a path without special arrangements for different types of links.

Turning now to the drawings, fig. 1 illustrates a diagram of an example of a path 100 having at least one section and at least one junction encoded according to the principles of the present disclosure. The path 100 includes a starting tip 110, a first cubic bessel section 120, a connection 130, a second cubic bessel section 140, and an end tip 150. Starting tip 110 and end tip 150 are examples of non-connecting joints, and connection 130 is an example of a connecting joint. The starting tip 110 and the end tip 150 are examples of rounded tips. Other types of vertices may be similarly encoded, such as rectangular vertices, triangular vertices, or even no vertices. The connection 130 is an example of a circular connection. Other types of connections may be similarly encoded, such as beveled (measure), triangular (triangle), pointed (miter), truncated pointed (truncated) and reverted pointed (reversed miter).

Control points 161 through 167 of path 100 are also shown. Control points 161, 164, and 167 are interpolation control points shared between different links. Control point 161 is shared between the starting tip 110 and the first cubic bessel section 120, control point 164 is shared between the cubic bessel section 120, the connection 130, and the second cubic bessel section 140, and control point 167 is shared between the second cubic bessel section 140 and the end tip 150. Advantageously, the shared control point may be indexed multiple times in the data structure and reduce the amount of storage capacity required. Control points 162, 163, 165, and 166 are extrapolated control points.

The coordinate values for the linked control points 161 to 167 are also shown as x, y coordinates in fig. 1. Fig. 10 to 14 show different links of the path 100 and examples of corresponding control point coordinate arrays of the path 100 comprising coordinate values. Fig. 10-14 also include examples of data structures, indexed links, for encoding each different link. The path 100 may be provided to a stroking system, such as that shown in fig. 2, for generating a stroked representation of the path. The stroking system may be a polar stroking system operating in accordance with method 500 of fig. 5.

Fig. 2 illustrates a block diagram of an example of a stroking system 200 configured as an encoding path in accordance with the principles of the present disclosure. The stroking system 200 may be, or be part of, a renderer for stroking tessellation of the drawing path. The stroking system 200 may be a polar stroking system that performs stroking using an encoded path. The system for depicting 200 may be located on a single computing device or distributed across multiple computing devices. The computing device may be, for example, a laptop computer, a desktop computer, a computing pad, a smart phone, or a server. The computing device may include at least one screen for displaying the path. The computing device may also be or be used to control a machine. For example, the stroking system 200 may be associated with or integrated with a machine such as a printer that prints a path or a CNC machine that processes material using the path. In some examples, the stroking system 200 is part of a cloud-based server, which may be used for cloud-based rendering, as well as for game streaming. The game flow allows users to control and play remotely rendered games from their input devices, such as keyboards, game controllers (including virtual reality input controllers), and mice. The cloud-based rendering platform and game flow may allow users to remotely compete with others in a video game over a communication network. The stroking system 200 includes a path processor 210 and a stroking processor 220. The stroking system 200 may include more than one path processor 210 or more than one stroking processor 220. The path processor 210 may be a Central Processing Unit (CPU) or a Graphics Processing Unit (GPU). In one example, path processor 210 is a CPU and stroke processor 220 is a GPU. Advantageously, the GPU may comprise a plurality of parallel processors to allow parallel processing of multiple links. In some examples, path processor 210 and stroke processor 220 may be a single processor.

The stroking system 200 is configured to receive a path to be represented and generate an encoded path representation. The received path may be in the form of code representing a linked generation equation for the path, such as an SVG path command. The generation equation for each link includes the control points for that link. The path may come from, for example, a Web browser, a document viewer, a navigation or mapping system, or an illustration application, such as a vector graphics program. The received path may be simple, such as path 100 of fig. 1, or complex, with various types of segments and junctions forming a sequence in various combinations.

The path processor 210 is configured to break up the received path into links, such as sections, top ends and connections of the path 100, and encode the links for storage using the same data structure for each link. The data structure may be an indexed link as disclosed herein. For example, the path processor 210 may receive the path 100 and break the path 100 into various segments, tops, and connections shown in FIG. 1 and encode the segments, tops, and connections for storage. The encoded links may be stored in the memory of the stroke processor 220. In this way, path processor 210 encodes the links into a format that can be stored and read by stroke processor 220. The encoded links and linked control points are downloaded to the stroke processor 220 to represent the path 100. The path processor 210 may be configured to perform additional processing on the link to enable the stroke before instructing the stroke processor 220 to generate a stroke representation of the link. The additional processing may correspond to processing performed by the CPU 310 of fig. 3.

At this point, path processor 210 sends a command to stroke processor 220 instructing stroke processor 220 to generate a stroke representation of the path link. The stroked representation may be a polar stroked representation. Commands may be sent from path processor 210 to stroke processor 220 through a programming interface, where the commands appear as function calls. The links may be generated as primitives (e.g., patches) or as tasks. The generated polar stroked representation may be used to visually represent the path. For example, the stroke processor 220 may provide the stroke representation to a computing device screen to display the path. The computing device may be, for example, a laptop computer, a desktop computer, a computing pad, a smart phone, or another type of computing device having a screen capable of displaying a polar stroke representation. The stroke processor 220 may also provide a stroke representation to print a path or operate a machine that takes the path. For example, the stroking system 200 may be integrated with a printer that employs a stroking representation to print a path.

The stroke processor 220 may be configured to generate a stroke representation based on the encoded path generated by the path processor 210. The stroke processor 220 may operate in accordance with the polar stroke algorithm disclosed herein. Accordingly, the stroke processor 220 may efficiently encode the algorithms disclosed herein, such as the algorithm represented by the flow chart of fig. 5.

The stroke processor 220 may generate linked stroke representations in parallel. In some examples, the stroke processor 220 may generate stroke representations of multiple paths in parallel. Thus, the stroke processor 220 may operate on multiple paths in parallel, while also operating on multiple links of those paths in parallel. As used herein, "parallel" includes at least partially parallel, and indicates that processing occurs in parallel paths, but not necessarily simultaneously.

The stroking processor 220 may be a GPU and operates in accordance with a graphics pipeline, with certain steps of polar stroking occurring at particular stages along the graphics pipeline. The stroke processor 220 may provide stroke functionality, such as polar coordinate strokes, via one or more shaders of the graphics pipeline. Alternatively, the encoded path may be stroked using other methods for stroking paths (e.g., uniform parametric curve subdivision). A shader is a program that performs a particular function or functions at a particular stage of the graphics pipeline. A polar stroke shader is an example of a shader that has been programmed to perform the polar stroke functions disclosed herein. The polar stroking shader may perform additional functions that are typically included in a graphics pipeline, or may be performed as part of one or more shaders of a graphics pipeline. The stroke processor 220 may employ one of different examples of graphics pipelines such as those shown in fig. 3 or fig. 4.

FIG. 3 illustrates a block diagram of an example of a renderer 300 in accordance with the principles of the present disclosure, the renderer 300 including a graphics pipeline configured to perform polar coordinate stroking. The renderer 300 provides an example of a system for polar stroking, such as the stroking system 200 of fig. 2. The renderer 300 renders the path using polar tracing. The renderer 300 includes a CPU 310, a GPU 320, and another hardware component, a memory 330.

CPU 310 is configured to accept or receive the path, decompose the path into links, encode the links using the same data structure for each link, and download the links and control points to GPU 320 through graphics commands. CPU 310 is also configured to bind the polar shader of GPU 320. Binding may include establishing the current configuration for the polar shader and setting variables. CPU 310 also sets a uniform variable (uniform) for the polar stroke shader. The values of the uniform variables are unchanged during shader processing. A uniform variable is a constant over the duration of the polar stroking process. For example, the stroking width may be set to 5. Another part of the configuration may include transforming the coordinate space of the path by rotation, translation, scaling or projection. At this point, the CPU 310 sends a command to the GPU 320 instructing the GPU 320 to draw a link of a path. Commands may be sent from CPU 310 to GPU 320 through a programming interface, where the commands appear as function calls. As described above, the links may be drawn as patches or tasks. Other primitives (e.g., triangles) may also be employed by the graphics pipeline for rendering.

GPU 320 includes a programmable graphics pipeline 321 for processing primitives representing paths. This primitive may be a patch and will be used as an example primitive to discuss the operation of graphics pipeline 321. Graphics pipeline 321 includes a vertex puller 322, a vertex shader 323, a tessellation control shader 324, a tessellation generator 325, a tessellation evaluation shader 326, a primitive component and rasterizer 327, and a fragment shader 328. Some of the stages, such as vertex pullers 322, tessellation generator 325, primitive components, and rasterizer 327, are fixed-function GPU stages of graphics pipeline 321. The other illustrated stages, namely vertex shader 323, tessellation control shader 324, tessellation evaluation shader 326, and fragment shader 328, are programmable shader GPU stages of graphics pipeline 321. A GPU capable of using OpenGL 4.0, OpenGL for Embedded Systems (ES)3.2, Direct3D 11, or similar graphics application programming interfaces provides such a programmable graphics pipeline 321 with these stages. OpenGL 4.0 and OpenGL ES 3.2 are available from Khronos Group, Inc. of Bifton, Oreg, while Direct3D 11 is available from Microsoft corporation of Redmond, Washington. GPUs available from Nvidia, Inc. of Santa Clara, Calif., such as GPUs with Volta or Pascal architectures, are examples of GPUs that may provide programmable graphics pipeline 321. As described below with reference to FIG. 5, various stages of graphics pipeline 321 may also be configured to perform the steps of polar stroking method 500.

Vertex fetcher 322 is the first stage of graphics pipeline 321, which fetches the vertices of the patch. Vertex shader 323 then describes various characteristics of each vertex. The tessellation control shader 324, tessellation generator 325, and tessellation evaluation shader 326 cooperate to tessellate a patch into a triangular mesh or connected lines. The tessellation control shader 324 and the tessellation evaluation shader 326 are two programmable stages for GPU tessellation, while the tessellation generator 325 is a fixed-function GPU stage. The tessellation control shader 324 performs patch-wide computations, such as computing the level of detail (LOD) for each patch, as the first stage of the GPU tessellation. Tessellator generator 325 decomposes the patch into a new set of primitives using the tessellation level and assigns coordinates for each vertex. Tessellation evaluation shader 326 evaluates the mesh vertices based on information provided by tessellation control shader 324 and tessellation generator 325. The tessellation evaluation shader 326 computes the position of each vertex from the tessellation generator 325, controls the tessellation pattern, and specifies the direction of the patch generated.

In the example representation of links intended for pipeline 321, a patch with six control points encodes each link. 10-15 illustrate examples of arrays of indexed links in which each indexed link includes six control points. Six control points are sufficient to index the four control points of the cubic Bessel section, and the other two are sufficient to index the initial and end gradient control points. Other types of links require fewer control points. A special control point index value (e.g., zero) may be used to encode a particular type of link. The skilled practitioner will recognize that such a linked representation is well suited for the vertex puller 322 and may be compactly stored in memory.

The primitive components and rasterizer 327 divides the resulting tessellation patch generated by tessellation evaluation shader 326 into a sequence of individual rasterized primitives (typically triangles) for rendering. Fragment shader 328 then computes the color and other attributes of each pixel of the base patch. Memory 330 receives pixel updates from fragment shader 328 of programmable graphics pipeline 321. Memory 330 includes a frame buffer 334 that stores received pixel updates, which provide an image for display. In this example, the image is a stroked tessellation of the path. In some examples, memory 330 is a video memory in which a series of stroked tessellations are encoded into a video stream.

The key details to accomplish tessellation appropriate for path delineation from programmable graphics pipeline 321 are not apparent. The tessellation generator 325 typically generates a dense rectangular 2D mesh, the width and height of which is limited to 64 on one side. Tessellation of a stroked-path segment, vertex, or connection typically needs to be tessellated into long-strip quadrilaterals (of duration 100s), rather than dense meshes. To accurately subdivide links requiring a large number of subdivisions, the subdivided bars may need to be many times longer than the maximum width or height (typically 64 for any one) of the dense grid that subdivision generator 325 may generate. One non-obvious technique, referred to herein as NaN poisoning (NaN poisoning), expressed as a non-number or NaN, which is an invalid floating point value, divides a dense grid into appropriate (possibly long) bands to delineate arbitrary links. In an example use of programmable graphics pipeline 321, a polar stroker shader executing on tessellation evaluation shader 326 generates a NaN value for the location of the vertex of a triangle to discard. The primitive component and rasterizer 327 cannot process rasterized primitives that have one or more NaN position values, and therefore must discard any such "NaN poisoned" primitives. The remaining non-discarded triangles have (non-NaN) vertex positions computed by the tessellation evaluation shader 326, and therefore, when processed by the primitive component and rasterizer 327, these triangles will be stitched together into a long strip to form a continuous triangle strip corresponding to the intended stroked tessellation. Orchestrating NaN poisoning and stripe seaming involves a polar stroking shader running on the tessellation control shader 324 to feed the appropriate meshes and related parameters to the tessellation generator 325 and the tessellation evaluation shader 326.

FIG. 4 illustrates a block diagram of another example of a renderer 400 including a graphics pipeline configured to perform polar coordinate stroking in accordance with the principles of the present disclosure. The renderer 400 provides another example of a system for polar-coordinate stroking. The renderer 400 includes a CPU 410, a GPU 420, and a memory 430. GPU 420 includes a graphics pipeline 421, and graphics pipeline 421 similarly provides tessellation of linked edges as does graphics pipeline 321 for GPU 320 in FIG. 3. However, the GPU tessellation of graphics pipeline 421 is provided by two programmable stages, by task shader 424 and mesh shader 426, rather than the tessellation control shader 324, tessellation generator 325, and tessellation evaluation shader 326 of graphics pipeline 321. Other components of graphics pipeline 421 and renderer 400 may be configured and operate as the same named components of graphics pipeline 321 and renderer 300 of FIG. 3. Thus, fragment shader 428 is another programmable shader GPU stage, and primitive components and rasterizer 427 are fixed-function GPU stages. GPUs available from Nvidia corporation, such as a GPU with a Turing architecture, are one example of a GPU that may be used for programmable graphics pipeline 421. Path processor 210 of fig. 2 may operate as CPU 310 of fig. 3 and CPU 410 of fig. 4. While graphics pipeline 321 operates on patches that represent each link, graphics pipeline 421 operates on tasks that may represent one or more links, and also generates spawned mesh shader instances to generate the necessary tessellations.

The task shader 424 is programmed to perform the functions of the vertex shader 323 and the tessellation control shader 324 of FIG. 3. Thus, unlike FIG. 3, task shader 424 determines various characteristics of each vertex of its one or more links and reads the vertex data itself, which in FIG. 3 is pulled by fixed function vertex puller 322. Task shader 424 then performs the computations within the patch-wide as the first stage of the GPU tessellation, similar to tessellation control shader 324.

Mesh shader 426 is configured to perform the remaining GPU tessellation functions, including breaking up one or more links into a new set of primitives through polar tracing, assigning coordinates to each vertex, and evaluating mesh vertices. The mesh shader 426 is also configured to compute the position of each vertex and control the tessellation pattern of the output mesh. Primitive components and rasterizer 427 then divides the resulting mesh into a sequence of individual triangles for rendering, and fragment shader 428 computes the color and other attributes of each pixel that is substantially linked. The pixel updates are then provided to a frame buffer 434 of the memory 430 for the stroked tessellation of the display path. As noted below with reference to FIG. 5, task shader 424 and trellis shader 426 may also be configured to perform the steps of polar tracing method 500.

Fig. 5 illustrates a flow diagram of an example of a polar stroking method 500 for generating a polar stroking representation using an encoded path as disclosed herein. Polar-coordinate stroking representations may be used for stroking tessellation. As such, some steps of method 500 may map to a GPU, such as GPU 320 or GPU 420. As described below, different stages of

programmable graphics pipelines

321 and 421 may be configured to perform at least some steps or specific functions of polar stroking method 500. At least some of the steps of method 500 may also be performed by stroking system 200 of fig. 2.

The method 500 basically includes two steps: a polar stroking meditation is determined for each link of the path, and the polygons used to generate the polar stroking representation of each link are evaluated using the polar stroking meditation. For the method 500, a quadrilateral will be used as an example polygon. The method 500 begins at step 515 with the receive path. The path may be a preprocessed path, such as the path received from path processor 210 of fig. 2.

The method 500 proceeds to step 516 where it is determined whether there is a link for the path to be processed. The link may be a segment or a junction. The number of links and the type of links will vary depending on the path. For the initial run of method 500, there will be at least one link for the path to be processed. When there are no additional links for the path to be processed, the method 500 continues to step 590 and ends.

When there is a link (i.e., an initial link or a next link) for the path to be processed, the method 500 continues to step 518 where the type and index of the link is read. The type and index of the link may be read from the indexed link representing the path. The type of link may be, for example, a section, a top, or a connection represented by the link of path 100. For example, the link may be a beginning tip, an end tip, or a connection, such as a pointed connection or an angled connection. The index of the link indicates the start and end of the link.

In step 520, the linked control points are read. The control points may be determined from indexed links for each link, which index to an array of coordinate control points for the path. As described above, each link has a generative equation that includes control points that define the link. For method 500, the characterization of the link includes the link type, index, generation equation, and control points. With respect to programmable graphics pipeline 321,

steps

518 and 520 may be performed by vertex fetcher 322.

In some cases, such as window space delineation, the control points are also transformed in step 530 as needed. The transformation control points take into account any rotational, translational, scaling or perspective transformation for the polar stroked representation of the path. With respect to programmable graphics pipeline 321, step 530 may be performed by vertex shader 323, while the following step 540 may be performed by tessellation control shader 324.

In step 540, the polar stroked middle bits of the link are computed. The polar delineation neutral position can be calculated from the control points using the tangent of the arc. The polar delineation intermediate positions include N, p, Ψ, δ, Δ_Σ. N is the number of quadrilaterals required for polar delineation of the link. p is an ordered sequence of parameter values t defining a link. The first p of the sequence is always zero and the last p of the sequence is always 1. Each intermediate bit p between the first p and the last p is the position where the inflection point of the link is located. The inflection point is the location where the link changes the direction of the bend. The number of inflection points may vary depending on the type of link. For example, a cubic bezier curve may have at most two inflection points.

Ψ is the tangent angle corresponding to each element p of the ordered sequence. For the first p, Ψ indicates the angle at which the link is initially oriented. For the last p, Ψ indicates the angle at which the link terminates. For each meditope p, Ψ indicates the tangent angle of its respective inflection point.

Delta is the number of degrees to step along the different intervals of the links between inflection points, and delta_ΣIs along each of the linksThe cumulative number of integer steps to be taken in an interval. N, p, Ψ, δ, Δ_ΣIs any symbol used to represent the nature of a link that can be used for polar delineation. Those skilled in the art of differential geometry can calculate these polar stroked median values. For example, the hodogram of the linked generator equation may be used to determine at least some polar stroked median values.

Once the polar stroked middle position is obtained, it is used to determine the quadrilateral. Determining the quadrilateral is an iterative process that begins at step 550 and proceeds to step 560 by selecting a rib (rib). The ribs are one side of a quadrilateral whose length is equal to the width of the stroke of the path. A pair of continuous ribs may form a quadrilateral. For the initial rib of the rib pair, the index value may be set to zero. The position and normal of the rib are evaluated in step 570 and the apex of the rib is generated in step 572. With respect to programmable graphics pipeline 321,

steps

550 and 560 may be performed by tessellation generator 325, and steps 570 and 572 may be performed by tessellation evaluation shader 326. Each rib is independent and can be processed in parallel.

In step 574, it is determined whether a pair of ribs has been evaluated. For the initial rib, a determination may be whether more than one rib is selected for the link. As shown in fig. 5, the determination may be made by comparing the current index value of the selected rib with zero. If a pair of ribs has not been evaluated, the method 500 continues to step 580 where a determination is made as to whether there are more ribs to process linked. When there are no additional ribs to process, the method 500 continues to step 590 and ends. For the first pass through the iterative ribbing process, there will be another ribbing to process. When there is at least one rib to process, the method 500 returns to step 560 and the next rib is selected. At this point, the index may be increased by one for the next rib. The position and normal of the next rib is evaluated in step 570 and the vertex of the next rib is generated in step 572. It is then determined in step 574 whether a pair of ribs has been evaluated. If false, the method 500 continues to step 580. If so, then a quadrilateral is generated for rasterization in step 576. The quadrilateral is defined by vertices of the pair of ribs. The quadrilateral may be provided to a rasterizer, such as the primitive components and

rasterizers

327 or 427 of fig. 3-4. Alternatively, the quadrilateral may be split and represented as two triangles sharing a common edge. From step 576, method 500 proceeds to step 580 and continues. The index of the rib may be reset to zero, for example, in

steps

576 or 580, to further indicate the rib pair in an iterative process. Other counters or comparison values may also be used to determine rib pairs. For example, a mesh shader approach as in fig. 4 may generate pairs of ribs to match the thread parallelism of a mesh shader instance.

The steps of generating the vertices of the ribs and then generating the quadrilateral are repeated for each rib of the link. When it is determined in step 580 that there are no more ribs to link, the method 500 continues to step 516, where it is determined whether there is another link for the path to process in step 516. If the path has no more links, the method 500 continues to step 590 and ends. All generated quadrilaterals used for path linking may then be used, for example, to render the path into a stroked subdivision. If there are more links to process, the method 500 continues to step 518 to continue with the next link. As described above, different stages of programmable graphics pipeline 321 may be configured to perform the specified steps of method 500. With respect to programmable graphics pipeline 421, task shader 424 can be configured to perform steps 518 through 550, and mesh shader 426 can be configured to perform

steps

560, 570, 572, 574, and 576.

Although presented as an iterative process, all of the rib iterations may operate independently, and thus at least part of method 500 may be performed in parallel, e.g., on a GPU. Multiple processing groups of ribs may be evaluated in parallel, and one or more GPUs may be used to process the linked multiple processing groups in parallel. In one example, a sequence of 32 ribs was evaluated in parallel. Furthermore, several such sequences of up to 32 ribs can be evaluated simultaneously in parallel. In some examples, ribs from eight links are processed simultaneously.

As described above, the method 500 may also be used to generate the tip and the connection. Vertex in a vector graphics systemEither circular, square, triangular or omitted. In polar delineation, the top is treated as a degenerate link where the control points are all co-located at the anchor point of the top. The polar stroked meditope N, p, psi, delta can be calculated_ΣSo that the geometry of the tip can be generated using the same rib iteration process applied to the curved section. It is complicated to tip by distinguishing between "inner" and "outer" radii, so the inner radius is usually forced to zero for the tip. The square tip is further complicated by scaling the outer radius of the rib at the corners of the square tip by the square root of 2 (1.414 …). These increases in complexity of the ribbing process due to the tips are straightforward and impose minimal overhead on the non-tip-linked ribbing process.

Similarly, connections in a vector graphics system may be circular, beveled, pointed, triangular, or omitted. In polar tracing, the connection is treated as a degenerate link where the control points are all co-located at the junction of the connections. The polar stroked meditope N, p, psi, delta can be calculated_ΣSo that the geometry of the tip can be generated using the same rib iteration process applied to the curved section. As with the tip, the connection becomes complex by distinguishing between "inside" and "outside" radii, so for a connection the inside radius is usually forced to zero. By calculating the cusp points of such connections, and if the cusp points exceed the specified cusp limits of the path (depending on the cusp connection pattern), truncating the cusp or reverting to an oblique angle connection, makes the cusp connection more complex. The increased complexity of the ribbing process due to the connections is straightforward and imposes minimal overhead on the ribbing process of the non-connected links.

Various examples of path segments are shown in fig. 6-9 to show representations of path segments as data structures that reference an array of control point coordinates for a particular segment and are used to encode each different segment. In fig. 6 to 9, the control point coordinate array includes a combination of a null value and a coordinate value of the control point of the segment. Each of the example data structures of fig. 6-9 is an indexed link. The indexed links in fig. 6-9 have six coordinate indices designated as indices 0 through 5, with four of the six indices being designated as position control points for different path segments and two indices being designated as gradient control points for different path segments. The position control point index refers to the coordinate value of the path segment in the control point coordinate array, and the gradient control point index refers to the coordinate value of the gradient control point of the path segment. Each link type is compactly encoded using a null value, as disclosed later in fig. 16, so the path segment data structure advantageously does not require data other than its index.

Fig. 6 shows a cubic bezier section 600, a corresponding control point coordinate array 610 and indexed links 620. The cubic Bessel section 600 includes four control points, represented as a first control point 602, a second control point 604, a third control point 606, and a fifth control point 608, each having coordinate values stored in a control point coordinate array 610. The control point coordinate array 610 has ten index slots or indices that include coordinate values of the first, second, third and fourth control points 602, 604, 606 and 608 in indices 2 through 9, and a null value in indices 0 through 1. The position control point indices 0 through 3 of the indexed link 620

reference indices

2, 4,6, and 8 of the control point coordinate array 610. The gradient control point indices 4 to 5 of the indexed link 620

reference indices

4 and 6 of the control point coordinate array 610, which are coordinate values of the gradient control points of the cubic bezier section 600.

Fig. 7 shows a (irrational) quadratic bezier section 700, a corresponding control point coordinate array 710 and indexed links 720. The (irrational) quadratic bezier section 700 includes three control points, represented as a first control point 702, a second control point 704, and a third control point 706, each having coordinate values stored in a control point coordinate array 710. The control point coordinate array 710 has eight indexes including coordinate values of the first, second and third control points 702, 704 and 706 in indexes 2 to 7, and null values in indexes 0 to 1. The position control point indices 0 through 3 of the indexed link 720

reference indices

2, 4, 0 (null), and 6 of the control point coordinate array 710. The position control point index 2, which points to the 0 (null) index value in the control point coordinate array 7120, encodes that the section is quadratic, rather than cubic, and reflects the fact that only three control points are needed for a quadratic bezier curve section. The gradient control point indices 4 to 5 of the indexed link 720 all reference index 4 of the control point coordinate array 710, which is the coordinate value of a single gradient control point of the (irrational) quadratic bezier section 700. As will be clear when discussing fig. 8, it is advantageous that the index of the second control point 704 is an even value (4) to specify that the section is a irrational quadratic bezier section rather than a rational quadratic bezier section.

As shown in FIG. 7, by assigning a null index to index 2 of indexed link 720, indexed link 720 is identified as a secondary Bezier segment that requires three (rather than four) control points. FIG. 8 shows an example of a cone (rational quadratic Bessel) section 800, in this case an ellipsoid arc, encoded by the null index of index 2 and the odd vertex index (5) of index 1 of the indexed link 820, indicating that the extrapolated control point for the cone section should be an (x, y, w) location, rather than a simple (x, y) and appropriately fetched and transformed. Thus, the combination of the odd index of index 2 (index 5 of control point array 810) and the null index of index 1 indicates that the segment encoded by indexed link 820 is not only a regular (irrational) quadratic bezier segment, but also a cone segment (which is a rational quadratic bezier segment). In addition to the cone section 800 and the indexed links 820, FIG. 8 also includes a control point coordinate array 810.

The conical section 800 includes three control points, represented as a first control point 802, a second control point 804, and a third control point 806, each having coordinate values stored in a control point coordinate array 810. Those skilled in the art will recognize that values encoding rational quadratic bezier sections, as such rational sections can accurately represent cones including circular arcs, elliptical arcs, and hyperbolas, as opposed to irrational quadratic bezier sections, which are limited to representing parabolic sections. Since any rational quadratic bezier curve encoding the cone can be normalized so that only the second control points are rational, encoding of rational quadratic bezier sections requires second control points that support three components (x, y, w). The control point coordinate array 810 has ten indices, including coordinate values of the first control point 802 in indices 2 through 3, coordinate values of the second and third control points 804 and 806 in indices 5 through 9, and a null value in indices 0 through 1. The control point coordinate array 810 does not provide a specific value for index 4 because the even index value of 4 is skipped and index 5 (odd) is used instead to designate the section as a rational quadratic bezier section and encode the three-component homogeneous coordinates of the second control point 804. The skilled practitioner will recognize how this encoding effectively distinguishes irrational (even index) and rational (odd index) quadratic bezier sections and allows for a second control point 804 of three components (x, y, w). The position control point indices 0 through 3 of the indexed link 820

reference indices

2, 5, 0 (null), and 8 of the control point coordinate array 810. The gradient control point indices 4 through 5 of the indexed link 820 reference index 5 of the control point coordinate array 810, which are coordinate values of a single gradient control point of the cone section 800.

Fig. 9 shows a line segment 900, a corresponding control point coordinate array 910, and an indexed link 920. The (irrational) quadratic bezier section 900 includes three control points, represented as a first control point 902 and a second control point 904, each having coordinate values stored in a control point coordinate array 910. Control point coordinate array 910 has six indices including coordinate values of first control point 902 and second control point 904 and null values in indices 0 through 1. The position control point indices 0 through 3 of the indexed link 920

reference indices

2 and 4 of the control point coordinate array 910. The gradient control point indices 4 through 5 of the indexed link 920

reference indices

4 and 2 of the control point coordinate array 910. The skilled practitioner will recognize that any encoding of the coordinate values of

indices

2 and 4 in indexed linked

index values

1 and 2 will also produce line segments.

Although fig. 6-9 illustrate examples of path segments and indexed links and arrays of control point coordinates for each of the respective path segments. 10-14 illustrate the path 100, various links of the path 100, an example of a control point coordinate array 1010 for the path 100, and an example of an indexed link for a particular link of the path 100 that references the control point coordinate array. The control point coordinate array 1010 includes sixteen indices, where indices 2 through 15 include control point coordinate values of the control points of the path 100, and indices 0 through 1 have null values. The indexed links of fig. 10-14 include six indices that reference a particular index of the control point coordinate array 1010 to encode a particular link of the path 100. Fig. 10-14 show the same data structure for all links of encoding path 100, including sections and junctions.

Fig. 10 shows indexed links 1020 for the start top 110 of the encoding path 100. Index 2 of indexed link 1020 references index 2 of control point coordinate array 1010, which includes the first coordinate of first control point 161 of path 100. The remaining control point indices 1 through 3 (and index 5) of indexed link 1020 reference index 0 and null values of control point coordinate array 1010. Index 4 references index 4 of the control point coordinate array 1010 and the first coordinate value of the gradient control point 162.

FIG. 11 shows indexed links 1120 for sections 120 of encoding path 100. Indexes 0 to 3 of indexed link 1120

reference indexes

2, 4,6, and 8 of control point coordinate array 1010, which includes the first coordinates of the four

control points

161, 162, 163, and 164 of section 120. Indices 4-5 reference the first coordinate values of

indices

4 and 6 of the control point coordinate array 1010 and the gradient control points 162 and 163 of section 120.

FIG. 12 shows indexed links 1220 for the connections 130 of the encoding path 100.

Indexes

0 and 2 through 3 of indexed link 1220 reference index 8 of control point coordinate array 1010, which includes the first coordinate of control point 164. Index 1 references index 0 of the control point coordinate array 1010 and the null value stored therein. Indices 4-5 reference the first coordinate values of

indices

6 and 10 of the control point coordinate array 1010 and the gradient control points 163 and 164.

FIG. 13 illustrates indexed links 1320 used to encode segments 140 of path 100. Indexes 0 to 3 of indexed link 1320

reference indexes

8, 10, 12, and 14 of control point coordinate array 1010 including the first coordinates of the four

control points

164, 165, 166, and 167 of section 140; indices 4-5 reference the first coordinate values of

indices

10 and 12 of control point coordinate array 1010 and gradient control points 165 and 166 of section 140.

FIG. 14 shows the indexed links 1420 used to encode the end top 150 of the path 100.

Indexes

0 and 2 of indexed link 1420 reference index 14 of control point coordinate array 1010, which includes the first coordinate of final control point 167. The remaining control point indices 1 and 3 (and index 5) of indexed link 1420 reference index 0 and null values of control point coordinate array 1010. Index 4 references index 12 of the control point coordinate array 1010 and the first coordinate value 166 of the gradient control point.

FIG. 15 illustrates an indexed link sequence 1520 of the path 100 based on the respective indexed links of each link of the path 100 as illustrated in FIGS. 10-14. The indexed linked sequence 1520 represents a five-linked complete baked (baked) sequence of the path 100, which along with the control point coordinate array 1010 may be stored in memory and processed to render the stroked path. For example, the two arrays of fig. 15, control point coordinate array 1010 and indexed linked sequence 1520, may be stored in GPU video memory, sequentially packed into a single buffer, and then processed by a polar coordinate stroker, such as discussed above with respect to fig. 2-4, to render the stroked path of path 100.

FIG. 16 illustrates a flow chart of an example of a method 1600 of determining a type of link from an encoded indexed link, performed in accordance with the principles of the present disclosure. Method 1600 provides an example of decoding indexed links for the (irrational) quadratic bezier section and the cone (rational quadratic bezier) section in fig. 7 and 8, respectively. The method 1600 also decodes the start and end path top indexed links in fig. 10 and 14, and the link indexed links in fig. 12. Other methods of encoding the indexed links and thus decoding the encoded indexed links are possible in accordance with the principles of the present disclosure. All indexes mentioned in method 1600 are indexed links that index stored values of the control point coordinate array. The method 1600 may be performed by a path processor, such as the path processor 210 of FIG. 2. Method 1600 begins at step 1601.

In step 1605, it is determined whether index 1 is empty. If not, the method 1600 continues to step 1610 and determines whether index 2 is empty in step 1610. If not, the method 1600 determines in step 1615 that the link is a tertiary path segment. If, in step 1610, index 2 is determined to be empty, method 1600 continues to step 1620, where it is determined whether index 1 is even. If so, the method 1600 determines in step 1625 that the link is an irrational secondary path segment. If index 1 is not even, then method 1600 determines in step 1630 that the link is a rational quadratic (conical) path segment.

Returning to step 1605, if index 1 is empty, the method 1600 continues to step 1640, where it is determined whether index 5 is empty. If not, method 1600 determines in step 1645 that the link is a connection. If index 5 is empty, the method continues to step 1650 where it is determined whether index 3 is empty at step 1650. If so, a determination is made in step 1655 as to whether index 2 is empty. If so, the method 1600 determines in step 1660 that the link is the initial path top. If not, method 1600 determines in step 1670 that the link is the end path top.

Returning to step 1650, if index 3 is not empty, then the method 1600 determines in step 1680 whether index 2 is empty. If so, method 1600 determines in step 1685 that the link is the beginning dashed top (dash cap). If not, method 1600 determines in step 1670 that the link is at the top of the end dashed line. Skilled practitioners will recognize that certain vector graphics standards, such as the XML Paper Specification (XPS), provide a different top of the dashed line than the top of the end-point dashed line, and therefore it is advantageous to distinguish between these two types of tops.

Fig. 17 illustrates a block diagram of an example of a computing device 1700 configured to display a path in accordance with the principles of the present disclosure. Path 100 is used as an example. Computing device 1700 may be, for example, a laptop computer, a desktop computer, a computing pad, a television (including a set-top box), or a smart phone. Computing device 1700 includes a stroke system 1710 and a screen 1720. Computing device 1700 may also include additional components, such as a frame buffer, typically included in a computing device configured to display images on its screen. The stroking system 1710 may be configured to operate as the stroking system 200, the renderer 300, the renderer 400, or according to the stroking methods disclosed herein. The stroke system 1710 generates a representation of the path 100 and provides the representation to a screen 1720 to display the path 100. These representations may be tessellated geometric primitives. Screen 1720 may be a conventional screen of a computing device for displaying images.

Fig. 18 illustrates a block diagram of an example of a printer 1800 configured to utilize a stroked print path in accordance with the principles of the present disclosure. Path 100 serves as an example path. The printer 1800 includes a stroking system 1810, a controller 1820, and a print mechanism 1830. The printer 1800 may also include additional components typically included in printers configured to print images. The stroking system 1810 may be configured to operate as stroking system 200, renderer 300, renderer 400, or according to the polar stroking methods disclosed herein. The stroking system 1810 generates a stroking representation of the path 100, e.g., a curve-subdivided geometric primitive, and provides the stroking representation to the controller 1820. The controller 1820 employs the stroked representation to generate print commands to instruct the print mechanism 1830 to print the path 100 based on the stroked representation. The printing mechanism 1830 may be a conventional component of a printer, such as a pen for printing images. The printed path 100 is shown on a sheet of paper 1840.

Portions of the above-described apparatus, systems or methods may be embodied in or performed by various digital data processors or computers, which are programmed or store a series of executable programs of software instructions to perform one or more steps of the methods. The software instructions of such programs may represent algorithms and be encoded in machine-executable form on a non-transitory digital data storage medium, such as a magnetic or optical disk, Random Access Memory (RAM), magnetic hard disk, flash memory and/or Read Only Memory (ROM), to enable various types of digital data processors or computers to perform one, more or all of the steps of one or more of the above-described methods or functions, systems or devices described herein. The data storage medium may be part of or associated with a digital data processor or a computer.

A digital data processor or computer may include one or more GPUs, one or more CPUs, one or more other processor types, or a combination thereof. The digital data processor and the computer may be located adjacent to each other, near the user, in a cloud environment, in a data center, or a combination thereof. For example, some components may be located near the user, while some components may be located in a cloud environment or data center.

The GPU may be embodied on a single semiconductor substrate included in a system with one or more other devices (e.g., additional GPUs, memory, and CPUs). The GPU may be included on a graphics card that includes one or more memory devices and is configured to interface with a motherboard of a computer. The GPU may be an integrated GPU (igpu) co-located on a single chip with the CPU. A device having a configuration of, for example, necessary logic and/or features for performing one or more tasks, is for example designed, constructed or programmed.

Various aspects of the disclosure, including the systems and methods indicated in the summary, may be claimed. Each aspect mentioned in the summary may have one or more elements of the dependent claims presented below in combination.

Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.

Claims

1. A method of encoding a path, comprising:

receiving a path having a plurality of links, wherein the links include at least one section and at least one junction; and

generating an encoded path by encoding the links based on their position information, wherein the encoding employs the same data structure for each of the links.

2. The method of claim 1, wherein the data structure is an indexed link that specifies a control point for each of the links by indexing to the control point in a control point coordinate array.

3. The method of claim 2, wherein the array of control point coordinates includes at least one null value.

4. The method of claim 3, wherein the indexed links comprise at least six control point indices.

5. The method of claim 3, wherein the indexed link indicates a link type based on a presence or absence of a null index value.

6. The method of claim 2, wherein receiving the path comprises: receiving the control point for the link of the path, and the method further comprises: generating the control point coordinate array for the path from the coordinates of the control points.

7. The method of claim 1, wherein the link comprises at least two sections selected from the list consisting of: a cubic Bezier section, a quadratic Bezier section, a taper section, and a line segment.

8. The method of claim 1, wherein the junction is a connection.

9. The method of claim 1, wherein the junction is a tip.

10. The method of claim 1, further comprising subdividing the encoded path surface into geometric primitives with a stroking processor corresponding to stroked regions of the path.

11. The method of claim 10, wherein the stroke processor is a Graphics Processing Unit (GPU).

12. The method of claim 11, wherein the GPU rasterizes the tessellated geometric primitives into a frame buffer.

13. The method of claim 11, wherein the tessellation is performed by a programmable GPU tessellation shader executing on the GPU.

14. The method of claim 11, wherein the tessellating is performed by a mesh shader executing on the GPU.

15. A system for tracing a path, comprising:

a path processor configured to decompose a path into links and encode the links, wherein the links comprise at least one section and at least one junction, wherein the path processor is configured to encode the path using the same data structure for each of the links; and

a stroking processor configured to subdivide the encoded path surface into geometric primitives corresponding to stroked regions of the path.

16. The system of claim 15, wherein the data structure is an indexed link that specifies a control point for each of the links by indexing to a control point in a control point coordinate array of the path.

17. The system of claim 16, wherein the path processor is configured to generate the control point coordinate array from coordinates of the control point.

18. The system of claim 16, wherein the array of control point coordinates includes at least one null value, and the indexed link indicates a link type based on a presence or absence of a null index value.

19. The system of claim 15, wherein the at least one section is a cubic bessel section, a quadratic bessel section, a tapered section, or a line segment, and the at least one junction is a connection or a tip.

20. The system of claim 15, wherein the stroke processor is a Graphics Processing Unit (GPU).

21. The system of claim 20, wherein the GPU is further configured to rasterize the tessellated geometric primitives into a frame buffer.

22. The system of claim 20, wherein a programmable GPU tessellation shader executing on the GPU is configured to tessellate the encoded path tessellation into the geometric primitives.

23. The system of claim 20, wherein a vertex shader executing on the GPU is configured to subdivide the encoded path surface into the geometric primitives.

24. The system of claim 20, wherein the geometric primitives are polygons.

25. The system of claim 24, wherein the polygon is a quadrilateral.

26. A computing device comprising the system of claim 20 and a screen configured to display an image of the path based on the geometric primitives.

27. The computing device of claim 26, wherein the computing device is a smartphone.

28. A printer comprising the system of claim 20 and a printing mechanism configured to print the path based on the geometric primitive.

29. A renderer, comprising:

a first processor configured to decompose a path into links and encode the links as indexed links, wherein the links comprise one or more sections and one or more junction points; and

a second processor configured to generate a stroked tessellation of the path based on a polar stroked representation of each of the links using the indexed links.

30. The renderer as claimed in claim 29, wherein the first processor comprises a Central Processing Unit (CPU) and the second processor comprises a Graphics Processing Unit (GPU).

31. The renderer as recited in claim 30, wherein the GPU comprises a programmable graphics pipeline having a programmable shader stage and a fixed function stage configured to generate the polar stroked representation, wherein the programmable shader stage comprises at least one polar stroked shader.

32. The renderer as claimed in claim 29, wherein the indexed links specify a control point for each of the links by indexing to a control point in a control point coordinate array.

33. The renderer as claimed in claim 32, wherein the control point coordinate array comprises at least two null values and coordinates of the linked control points.

34. The renderer as claimed in claim 29, wherein the indexed links indicate a link type based on the presence or absence of one or more null index values.

35. The renderer as recited in claim 29, wherein the link comprises a section and a junction, the section being a cubic bessel section, a quadratic bessel section, a tapered section, or a line segment, the junction being a starting apex, an end apex, or a connection.

36. The renderer as claimed in claim 29, wherein the polar-coordinate stroked representation of each said link is a sequence of quadrilaterals.

37. A method of determining a type of link of a path from a data structure, comprising:

analyzing a data structure encoding a link, the data structure having a plurality of indices referencing arrays of control point coordinates corresponding to the link; and

determining the type of the link based on the presence of at least one index null value for at least one of the indexes.

38. The method of claim 37, wherein the type is a segment or a junction.

39. The method of claim 37, wherein the type is based on there being a plurality of indices having an index null.

40. A method of encoding a path comprising a plurality of segments and a plurality of junctions connecting respective successive adjacent pairs of the segments, the method comprising:

encoding the sections into first indexed links for each of the sections and using the same representation format for each of the sections; and

for each splice point, and using the same representation format, encoding the splice point as a second indexed link;

wherein each segment is a cubic Bessel segment, a quadratic Bessel segment, a conical segment, or a line segment;

wherein each junction is a tip or a connection; and

wherein the first indexed link and the second indexed link comprise a field whose value indicates whether a section or a splice point is encoded in a given instance.