AU766662B2 - Rapid detection of whether paths of arbitrary complexity intersect - Google Patents

Description

M1 S&F Ref: 551269

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name and Address of Applicant Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Michael Anthony Martin Spruson Ferguson St Martins Tower,Level 31 Market Street Sydney NSW 2000 Rapid Detection of Whether Paths of Arbitrary Complexity Intersect 0 0 ASSOCIATED PROVISIONAL APPJL CATION DETAILS [33] Country [31] Applic. No(s) [32] Application Date AU PQ7532 16 May 2000 The following statement is a full description of this invention, including the best method of performing it known to me/us:- IP Australia

CO

Documents received on: 1 MAY ZUUl CD Batoh No, 5815c -1- RAPID DETECTION OF WHETHER PATHS OF ARBITRARY COMPLEXITY INTERSECT Technical Field of the Invention The current invention relates to computer graphics and, in particular, to highspeed processing of graphical objects in computer-based systems to determine whether paths intersect.

Background Art Polygons are typically defined by a number of points, where the points are interconnected by line segments. A path may consist of one or more polygons. In the context of raster-based graphical systems, two paths are considered to intersect if, when they are rendered to a raster-based output device, there is at least one pixel filled by both paths.

Determining whether two paths intersect is often a fundamental operation of computer-based graphic systems. Such computer-based graphic systems typically include graphics development applications, printing systems, and games. Since determining whether two paths intersect is usually a graphic "primitive", or fundamental function, this operation will typically be called many times by higher-level operations. It is therefore a S 20 requirement for this operation to be fast.

-*Prior methods of determining whether two paths intersect, in the interest of high-speed processing, usually place constraints on the types of polygons that can be "examined. In particular, prior methods typically require that the polygons to be examined must be convex, not self-intersecting, or must not contain any degenerate segments. A 25 polygon is classified as being convex if it contains all the lines connecting any pair of its ::line segment end points. Self-intersecting polygons have at least two of their line segments crossing each other. Degenerate segments occur when two line segments of a Ipolygon are parallel and lie, at least partially, on each other. Other methods exists that can determine whether two paths of arbitrary complexity intersect, but these methods, mainly because of their complexity, are not particularly fast.

551269.doc Disclosure of the Invention It is an object of the invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to a first aspect of the invention, there is provided a method of determining whether two or more paths intersect on a rendered page, each of said paths comprising at least one polygon and each of said polygons comprising a plurality of spline segments, said method comprising the steps of: splitting said page into horizontal or vertical bands, such that each band contains monotonic spline segments; and processing each band independently until an intersection is detected or until all said bands have been processed, in which case no intersection between said paths exists.

According to another aspect of the invention, there is provided an apparatus for determining whether two or more paths intersect on a rendered page, each of said paths comprising at least one polygon and each of said polygons comprising a plurality of spline segments, said apparatus comprising: means for splitting said page into horizontal or vertical bands, such that each band contains only monotonic spline segments; and means for processing each band independently until an intersection is detected 20 or until all said bands have been processed, in which case no intersection between said :paths exists.

Brief Description of the Drawings One or more embodiments of the present invention will now be described with reference to the drawings, in which: :9 *•Figs.lA and 1B each show a star polygon filled with the odd-even fill rule and S the non-zero winding fill rule respectively; Fig. 2A shows a path with two polygons, and wherein each polygon has four line segments, filled using the inclusive render mode; Fig. 2B shows the same path as in Fig. 2A, but filled using the strict fill render mode; Figs. 3A and 3B illustrate two paths on a render surface and the render surface being split into bands, respectively; 551269.doc -3- Fig. 4 is an example of how the preferred implementation is used on two paths; Fig. 5 shows another example of two paths whose line segments cross, but their line segments cross in such a way that band skimming alone will not detect an intersection; Fig. 6 is a table of possible fill values for standard xlist entries; Fig. 7 is a representation of how standard and override xlist entries are derived from a path's line segments; Fig. 8 shows an example of how one line segment can produce one standard and two override entries; Fig. 9 illustrates the problem of horizontal "pixel overlap", wherein pixels of two paths intersect once rendered, but whose respective line segments do not actually cross; Fig. 10 gives an example of two paths that intersect when rendered, but require line segment tracing during the line segment crossover analysis phase to detect intersection; Figs. 1 lA and 1lB show how line segments are traced in a direction of divergence, and when the tracing routine can be terminated; S:i" Fig. 12 shows an example of two paths filled with the strict fill render mode, wherein line segments of the paths intersect, but the paths themselves, when rendered, do 20 not intersect; Fig. 13 shows how the xlist entries are adjusted to examine a pixel row within a band, for the strict fill render mode; Fig. 14 illustrates the use of optimisation procedures to avoid unnecessarily processing bands; 25 Fig. 15 is a flow diagram of a method of determining whether paths intersect; and Fig. 16 is a schematic block diagram of a general purpose computer upon which the preferred embodiment of the present invention can be practiced.

Detailed Description Including Best Mode The preferred implementation is a computer graphics system which handles graphical objects on a two-dimensional raster- or scanline-based output device. Such devices include printers and computer monitors. The output device has a coordinate 551269.doc space or page in which the x-axis is defined as positive from left to right, and the y-axis is defined as positive from top to bottom.

The system has the ability to define paths, such as the path 300 illustrated in Fig. 2A. Paths may consist of one or more polygons, where each polygon has at least three straight line segments. The path 300 in Fig. 2A consists of two polygons 310 and 320. Polygon 310 has line segments 311, 312, 313 and 314. Each polygon 310 and 320 must form a closed shape, but polygons 310 and 320 can be quite distinct from each other in the path 300. In other words, each path 300 describes a set of polygons 310 and 320, each having arbitrary complexity.

In addition, each path has a fill rule, which defines how its polygons are filled when rendered. Fill rules are generally based on a winding or fill count of the path. The fill count is a value that counts, in some fashion, the number of line segments crossed as a straight line is traversed through the path. The preferred implementation will be explained with respect to the odd-even rule, and the non-zero winding rule, but may be expanded to include any other fill rule.

Referring to Fig. 1A, a star polygon 330 filled with the odd-even fill rule is shown. The odd-even fill rule states that a given point is inside a polygon if a ray traced S:i" from the given point to infinity crosses an odd number of the polygon's line segments.

Therefore, one method of determining whether a region 340 lies inside or outside a given S 20 polygon 330, involves choosing a point 341 as a test point inside the particular region 340. Next, a ray 342 is formed that starts at the test point 341 and extends infinitely in any direction is chosen. If the ray 342 intersects line segments 331, 332, 333, 334 and 335 of the polygon 330 an odd number of times, then the region 340 is considered to be 0* S interior and is therefore filled. It can be shown that when this rule is applied to region 25 350, that this region is determined to be exterior to the polygon 330, and is therefore not o filled.

Referring to Fig. 1B, the same polygon 330 as in Fig. 1A is shown, but with the non-zero winding fill rule applied. This rule states that a given point is inside a polygon if a ray traced from this point to infinity crosses an equal number of upward- and downward-heading line segments. This rule therefore requires for each line segment 331, 332, 333, 334 and 335 to have an associated direction. To determining whether a region 340 lies inside or outside a given polygon 330, typically involves choosing a point 336 as a test point inside the particular region 350. Next, a ray 337 is formed that starts at the 551269.doc test point 336 and extends infinitely in any direction is chosen. If the ray 337 intersects line segments 331, 332, 333, 334 and 335 of the polygon 330, a winding count is incremented or decremented according to the direction of the intersected segment 331 and 333. A point n the polygon 330 is filled whenever the winding count is zero. Any point inside area 350 can be shown to be filled.

Furthermore, a render mode is defined for the page, causing all paths to have the same render mode. The render mode determines how pixels on the page are filled near the line segments. Referring again to Fig. 2A, the inclusive render mode is shown, in which every pixel touched by the path 300 is filled. Pixel boundaries are considered to be top-left inside and bottom-right outside. The inclusive render mode causes a pixel 315 to be filled, even though a larger part of the pixel 315 falls outside the polygon 310.

The strict fill mode is shown in Fig. 2B, applied to path 300 which is the same as that shown in Fig. 2A. In the strict fill mode only pixels whose centre point is inside the path 300 are filled. A convention is used whereby pixels whose centre points lie 15 directly on line segments, such as pixels 316, 317, 318 and 319, the crossing is taken as **occurring after the pixel centre as one traverses horizontally from left to right (ie. the x position of the crossing is rounded up). This convention causes pixels 316, 317 and 318 •to be filled, whereas pixel 319 is not filled.

The preferred implementation of determining whether polygons intersect is based on a scanline rendering approach. Scanline rendering involves moving horizontally across the page, one scanline or pixel row at a time, filling pixels appropriately as paths are crossed. A prior art "brute force" method of detecting path intersection would be to S simply examine every row of pixels in which the two paths lie to determine if any pixels on the row are filled by both paths. The preferred implementation seeks to minimise the 25 number of pixel rows that need to be examined without affecting the accuracy of the result.

Referring to Fig. 3A, two polygons 400 and 401 are shown. Also referring to Fig. 15, in an initial bandlines defining step 10 of a procedure 1 for detecting an intersect between paths, a page is split into horizontal sections or bands 411 to 414, such that each band 411 to 414 contains only straight line segments 402 to 409. This is also illustrated in Fig. 3B, which is an exploded view of Fig. 3A. For example, band 413 contains straight line segments 403a, 405a, 407a and 409a, which are parts of line segments 403, 405, 407 and 409 respectively.

551269.doc The horizontal lines 420 to 424 defining these bands 411 to 414 are termed bandlines. The bands 411 to 414 are defined in the bandlines defining step 10 by creating a ylist, which is a list of the y coordinates of all the bandlines 411 to 414, sorted in ascending order (ie. down the page). The bandline coordinates are found simply by taking the y coordinates of every start and end point of the line segments 402 to 409 in both polygons 400 and 401, and removing any repeated values. It is noted that the bandlines 411 to 414 can be constrained to lie (inclusively) between the lower top 430 and higher bottom 431 of the two polygons' boundaries, since only bands 411 to 414 containing segments 402 to 409 from both polygons 400 and 401 are significant. Each band 411 to 414 can then be considered independently of the others, and the bandlines 411 to 414 define which pixel rows need to be examined for that band 411 to 414.

Referring again to Fig. 15, a decision step 20 determines whether all the ylist entries or bands have been examined. If all the bands have been considered without finding an intersection, then a no intersect reporting step 70 reports that the paths do not •15 intersect. However, if all the bands have not been considered, then a band select step "selects the next band as the next entry from the ylist.

cosvrExamining a band broadly involves two steps: band skimming and segment crossover analysis. As illustrated in Fig. 4, band skimming follows the idea of scanline rendering. Moving horizontally from left to right along the bandline 450 at the top of the 20 band (not illustrated) and it is tracked whether each of the paths 460 and 470 is being •go.

filled. If, at any time, both paths are filled, they intersect. For example, starting at the left **and moving along bandline 450 towards the right, the bandline 450 intersects with path S 460, and in particular, a line segment 462 of a polygon 461 of path 460. Polygon 461 is filled from point 463 onwards, until a point 464 is reached where a line segment 465 of 25 polygon 461 is crossed. Similarly, polygon 471 which forms path 470, is filled from point 472 where the bandline 450 intersects the polygon 471.

From a point 466 where the bandline 450 intersects polygon 467, where polygon 467 is also part of path 460, path 460 is again filled. At this point 466 both paths 460 and 470 are filled. Therefore, an intersection between paths 460 and 470 has been detected and the band skimming ends.

However, while scanline rendering examines every pixel in the row, this method is only concerned with the pixels directly affected by the paths; so, in general, 551269.doc only the points where the paths cross the bandline are considered. These points are conveniently termed as crossings.

Referring again to Fig. 15, to implement band skimming, an xlist is created in a determine xlist step 30, which holds all the crossings for the bandline. These crossings are sorted in ascending order of x position (ie. from left to right across the page). Each path has a fill rule and a fill count to keep track of whether the path is filled or not. For paths with an odd-even fill rule, the fill count is incremented at every crossing for that path, and the path is filled whenever the fill count is odd. For those with a non-zero fill rule, the fill count is incremented or decremented depending on the direction of the segment at the crossing; the path is filled whenever its count is zero.

Following the determine xlist step 30, for each bandline, a band skimming step begins processing at the start of the xlist (leftmost crossing on the bandline). At each crossing, the fill count for the appropriate path is updated, according to its fill rule. If both paths are filled at the same time, processing in the band skimming step 40 terminates 15 following the dotted link 41 to a intersect reporting step 60. The intersect reporting step returns a positive result ie. that an intersect has occurred. It is noted that the rest of the bandline under consideration, and the rest of the bands are not considered once an .intersect has been detected.

The nature of the xlist entries depends on the render mode being used for the 20 operation. In particular, the inclusive render mode requires more information to be stored in the xlist than the strict fill mode. However, regardless of the render mode, xlist entries always have a field identifying which path they belong to, and an x position.

S .The procedure continues to a segment crossover analysis step 50. The segment crossover analysis step 50 is also greatly affected by the render mode used. This step 25 is required because paths can intersect within a band, and skimming alone will not detect this. An example of this is illustrated in Fig. 5. Performing the band skimming step along bandline 480, which defines the top of band 486, line segment 484 belonging to a first path (not illustrated) is crossed. The first path is therefore filled from this point 487 to point 488 where line segment 485 is crossed, line segment 485 also belonging to the first path. Continuing along bandline 480, it is determined that the first path and a second path, where the second path is partially defined by line segments 482 and 483, do not share common filled pixels along bandline 480.

551269.doc By repeating the band skimming step 40 along bandline 481, it can be shown that again no pixels are shared between the first and second paths along the bandline 481.

However, it is evident that an area 489 exists where the first and second paths do share common filled pixels.

Therefore, the procedure 1 continues to the segment crossover analysis step which identifies whether any line segments actually cross within the band, and then whether or not they cause pixels to be filled in common. The segment crossover analysis step 50 would separately be described for the inclusive render mode and the strict fill render mode.

The inclusive render mode requires two different types of xlist entries for the band skimming step 40, namely: 1. standard entries, used for line segments that cross the bandline, and 2. override entries, used for line segments that may not cross the bandline, but still affect the bandline pixel row (the row of pixels in which the bandline lies).

15 Each standard entry represents a crossing of a line segment with the bandline, S• "and holds a fill value for this crossing. The fill value is used to update the fill count of the .path to which the segment belongs. The table of Fig. 6 shows the possible fill values for different fill rules and segment directions.

Override entries ensure that all the pixels in the bandline pixel row that are o.ooo: filled by path segments are taken into account, despite the fact that those segments may not actually cross the bandline. For example, illustrated in Fig. 7, segments 501 and 502 above the bandline 500 itself, but they still lie in a bandline pixel row 506 defined by pixel boundaries 503 and 504.

Override entries do not represent crossings; they are used to mark pixels as 25 being filled that would otherwise be overlooked. Further, override entries do not have associated segments, and hold an override value rather than a fill value. Override values are always paired, with the leftmost entry (ie. with the smaller x coordinate) having an override value of and the rightmost having an override value of At point 505 where line segment 502 enters the bandline pixel row 506, and in particular, where it crosses pixel boundary 503, the override count is set to Similarly, at point 506 where line segment 501 exits the bandline pixel row the override count is set to -1.

As is shown in Fig. 8, a single line segment 510 crossing a bandline 512 can create up to one standard entry and two override entries. The standard entry corresponds 551269.doc -9to the point 511 where the line segment crosses the bandline 512, whereas the override entries correspond with points 513 and 514 where the line segment 510 enters and exits bandline pixel row 515 respectively.

Therefore, for the inclusive render mode, each path requires a fill count (updated by standard xlist entries) and an override count (updated by override xlist entries). A path is considered filled whenever its fill count indicates such (according to the path's fill rule), or whenever the override count is greater than zero. Note that the override count should never drop below zero; if it does, the xlist has incorrect override entries.

One further complication exists during the performance of the band skimming step 40 in the inclusive render mode, namely horizontal "pixel overlap" along the bandline. The override entries in general handle the fact that the pixels filled by a path can extend beyond the path's outline, but one case of this occurrence remains unaccounted for. An example of such an occurrence is shown in Fig. 9, where two paths 15 520 and 521 do actually intersect when rendered because at least pixel 522 is filled by both paths 520 and 521, but neither the standard entries nor the override entries produced by these paths will detect this overlap.

This exception is covered by some extra processing for some xlist entries.

Specifically, if a xlist entry causes its path to become unfilled, the next entry in the xlist is 20 examined to determine whether it is from the other path, and it is within the same oo•.

pixel as the current one. Only entries that cause their path to be unfilled require this extra step; if the current entry "fills" its path, the following entry will also fill its path, and S intersection will be detected in the normal flow of operation. Note that if the other path is already filled, intersection will have been detected before this point is reached along the 25 bandline.

Therefore, once the xlist has been processed in the band skimming step without finding an intersection, the bandline pixel row is "clear" from overlaps and the segment crossover analysis step 50 can begin.

The segment crossover analysis step 50 is concerned with segments intersecting within a band itself. If any segments from one path crosses any other segment from the other path, they fill pixels in common, and thus the paths intersect. This is straightforward to detect, simply by comparing every segment from the first path against every one in the second path. However, the horizontal pixel overlap effect comes into 551269.doc play again, where segments do not necessarily have to cross over to cause an intersection.

An example of this occurrence is shown in Fig. 10 where, even though paths 530 and 531 never cross, there exists a commonly filled pixel, and therefore an intersect between paths 530 and 531.

To make provision for this occurrence, the two segments need to be "traced".

This involves stepping down the two segments and determining which pixels are filled for each pixel row in the band. This is effectively the brute force method mentioned earlier, but in the preferred implementation, the use of this method is restricted to only two segments at a time. This allows for this method to be highly optimised, and only to be used in very specific cases namely: 1. The two segments must have the same "x direction", that is, each segment's change in x for increasing y must have the same sign.

2. The "x extents" of the segments must overlap if the rightmost point of the leftmost segment is at least one pixel to the left of the leftmost point of the rightmost segment, the segments cannot cause pixel overlap.

Further, if the tracing routine is executed in the direction of segment divergence (as opposed to always from the top of the band down), the routine can terminate as soon :i as the segments diverge by more than one pixel. Fig. 11A illustrates segments 540 and 541 diverging from top to bottom, whereas segments 542 and 543 illustrated in Fig. 11B °oeoo 20 diverge from bottom to top. In the case of Fig. 11 A, tracing starts at the top, whereas in the case of Fig. 11B, tracing is started at the bottom. The tracing routine can therefore :.:•:terminate at an earlier point than in a case where simply top to bottom tracing is always performed. Also, tracing is only necessary when the current (standard) xlist entry causes its path to become unfilled, by virtue of similar reasoning given above for the horizontal pixel overlap problem.

The strict fill render mode is considerably less complicated to process than the inclusive mode, but may be somewhat slower for the segment crossover analysis step Since only pixels whose centre point is inside the path's outline are filled, bandlines can be restricted to lie only on half-scanlines (ie. halfway between the horizontal pixel boundaries, or along the centre of the pixel row). Thus, when the ylist is created, every y coordinate is taken from both paths, then rounded to a half-scanline. The type of rounding used depends on how segments are rendered in the system. The preferred implementation rounds each y coordinate to the next half-scanline down the page. Since 551269.doc -11the ylist does not contain any repeated values, the number ofylist entries is typically fewer for this render mode than for the inclusive mode.

The xlist is created in a similar manner to that described above, but is greatly simplified for two reasons. Firstly, override entries are not required, since the problem of "pixel overlap" does not occur. Secondly, the x position of each entry can be rounded to pixel boundaries. This is due to the fact that the strict fill render mode is based on integer crossings. When rendering in this mode, each pixel row is processed along the halfscanline, and the x coordinates of segment crossings are rounded to the nearest pixel boundary. The band skimming step 40 is therefore quite fast, since the creation of the xlist in the determine xlist step 30 is simplified, and processing requires only one scan through the list for intersection based on the paths' fill counts. The strict fill render mode has no special cases.

Segment crossover analysis presents a much more difficult problem, however.

It is not sufficient to simply test if any segments intersect, since such an intersection does not guarantee that pixels will be filled by both paths. Fig. 12 illustrates a case where several segments 552 to 555 intersect, yet once rendered the paths 550 and 551 do not.

Furthermore, if an intersection occurs within the band (not illustrated), pixel overlap can occur anywhere between the point of intersection and the bottom of the band, but is not guaranteed to do so.

The algorithm must therefore rely on the brute force approach, by examining every pixel row from the point of intersection down to the next bandline. This can still be performed rapidly, however, by re-using the band skimming routine. By storing some extra information about the segments in the xlist when it is first created in determine xlist step 30, and in particular, the change in x per scanline step in y, the x positions of the xlist entires can quickly be adjusted to the next pixel row to be examined, and the band skimming operation can then be performed on the new "bandline".

Fig. 13 illustrates the segment crossover analysis step 50 for the strict fill render mode according to this method. Segments 560 and 561 form parts of a first path (not illustrated) whereas segments 562 and 563 form parts of a second path (not illustrated). Segments 561 and 562 cross at a point 564 between bandlines 565 and 566 defined in the bandlines defining step 10. Performing the segment crossover analysis step a new "bandline" 567 is defined with a y-coordinate of the first half-scanline below the point 564 where segments 561 and 562 cross. New xlist entries are also calculated for 551269.doc -12this new "bandline" 567 by adjusting each entry's x-position, using the change in x value.

Band skimming similar to the band skimming step 40 is performed along this new "bandline" 567. If no intersection is detected, then the new "bandline" 567 is moved one scanline step below its previous position, new xlist positions are calculated and band skimming is again repeated. Note that care must be taken to maintain the sorting of the xlist; if segments cross over, their x entries should be moved appropriately within the list.

Should an intersect be detected at any point while performing the segment crossover analysis step 50, processing terminates following the dotted link 51 to the intersect reporting step 60. Alternatively, once the segment crossover analysis step 50 has been completed, procedure 1 continues to decision step Having described the preferred implementation, some further means for improving the performance of the operation will now be described.

When creating the xlist in the determine xlist step 30, there are two tests that can be executed to allow procedure 1 to skip the currently selected band, thus avoiding unnecessary processing. Firstly, if only one path contributes entries to the xlist, the band can be skipped, as both paths must be present for an intersection to occur. Secondly, by tracking the minimum and maximum x positions of each path's entries in the xlist, the band can be skipped if the resulting "x extents" do not overlap.

20 Fig. 14 illustrates an example of both optimisations in use. Polygons 570 and 571 make up a first path, whereas polygon 572 makes up a second path. By tracking the minimum and maximum x positions of the first and second path's entries in the xlists of bandlines 575 and 576, bands 573 and 574 can be skipped since the resulting "x extents" do not overlap. Furthermore, since the xlist entries along bandlines 577 and 578 only contain contributions from the second path, bands 579 and 580 can also be skipped.

Depending on the system restrictions, once the ylist has been created in the decision step 20, the routine may either create one xlist at a time, processing each as it is defined, or create all the xlists at once. The first option uses as little memory as possible, but requires many passes through the path data, which impacts the speed of the operation.

The second option is the opposite, since it uses the maximum memory for the operation, but requires only one pass through the path data. It is also possible to compromise between the two alternatives by creating and then processing more than one xlist per pass 551269.doc 13through the paths. The method used depends on the required trade-off between speed and available memory.

A further refinement of the procedure 1 requires that all the xlists be created before processing begins (as in the second option above). In this case, it is possible to skim all the bands (as in the band skimming step 40) before performing the segment crossover analysis (as in the segment crossover analysis step 50). If the paths do intersect when rendered, band skimming alone will most probably detect this. Since segment crossover analysis is typically more expensive (in terms of speed) than skimming, it is advantageous not to perform it unless necessary.

An alternative method contrary to this refinement may be also used for the inclusive fill mode. It is possible to interleave the skimming and segment crossover analysis phases in one loop structure. Thus, when a standard xlist entry has been processed with respect to band skimming, it can then be checked against the remaining standard entries in the list for segment crossover. This refinement avoids multiple passes 15 through the xlist.

It should be understood that the invention is not limited to two paths and two render modes. It is quite easily extendable to more than two paths, and with some design effort to more than two render modes.

The method of determining whether paths intersect may be practiced using a 20 conventional general-purpose computer system 200, such as that shown in Fig. 16 wherein the processes of Figs. 15 may be implemented as software, such as an application program executing within the computer system 200. In particular, the steps of method of determining whether paths intersect are effected by instructions in the software that are carried out by the computer. The software may be stored in a computer readable medium, 25 including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for determining whether polygons intersect in accordance with the implementations of the invention.

The computer system 200 comprises a computer module 201, input devices such as a keyboard 202 and mouse 203, output devices including a display device 214.

The computer module 201 typically includes at least one processor unit 205, a memory 551269.doc 14unit 206, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (11O) interfaces including a video interface 207, and an I/O interface 213 for the keyboard 202 and mouse 203. A storage device 209 is provided and typically includes a hard disk drive 210 and a floppy disk drive 211. The components 205 to 213 of the computer module 201, typically communicate via an interconnected bus 204 and in a manner which results in a conventional mode of operation of the computer system 200 known to those in the relevant art.

Typically, the application program of the preferred implementation is resident on the hard disk drive 210 and read and controlled in its execution by the processor 205.

Intermediate storage of the program may be accomplished using the semiconductor memory 206, possibly in concert with the hard disk drive 210. In some instances, the application program may be supplied to the user encoded on a floppy disk and read via the corresponding drive 211.

The method of determining whether paths intersect may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the method. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, the line segments of the polygon may be curved lines or splines. A person skilled in the art will appreciate that any curved line may be broken up into a number of monotonically increasing or decreasing splines, and that the embodiments of invention 25 may be performed on these monotonic splines.

.Vo 551269.doc

Claims (4)

1. A method of determining whether two or more paths intersect on a rendered page, each of said paths comprising at least one polygon and each of said polygons comprising a plurality of spline segments, said method comprising the steps of: splitting said page into horizontal or vertical bands, such that each band contains monotonic spline segments; and processing each band independently until an intersection is detected or until all said bands have been processed, in which case no intersection between said paths exists.

2. A method as claimed in claim 1, wherein the processing step is only performed for bands containing spline segments from two or more of said paths.

3. A method as claimed in claim lor 2, wherein said processing step (b) comprises the steps of: (b l) determining crossings between an upper border of said band and said spline segments in said band; i" (b2) determining intersection between said paths along said upper border of 20 said band; and (b3) determining intersection between said paths within said band.

4. A method as claimed in claim 3, wherein the determining steps (b2) and (b3) considers fill modes of said paths. A method as claimed in claim 4 wherein, for an inclusive render mode, the determining step (b2) further includes determining an intersection between said paths and borders of a bandline row, the bandline row being the row that contains said upper border "of said band. goo

551269.doc -16- 6. A method as claimed in any one of claims 1 to 5, wherein said bands are horizontal and coordinates of borders of said bands being the vertical coordinates of start points and end points each of said spline segments of both said polygons, with repeated coordinates removed. 7. Apparatus for determining whether two or more paths intersect on a rendered page, each of said paths comprising at least one polygon and each of said polygons comprising a plurality of spline segments, said apparatus comprising: means for splitting said page into horizontal or vertical bands, such that each band contains only monotonic spline segments; and means for processing each band independently until an intersection is detected or until all said bands have been processed, in which case no intersection between said paths exists. 8. An apparatus as claimed in claim 7, wherein said means of processing only acts on bands containing spline segments from two or more of said paths. 9. Apparatus as claimed in claim 7 or 8, wherein said means for processing comprises: 20 means for determining crossings between an upper border of said band and said spline segments in said band; means for determining intersection between said paths along said upper border o%. of said band; and means for determining intersection between said paths within said band. Apparatus as claimed in claim 9, wherein said means of determining 0 intersection between said paths along said upper border of said band and said means for determining intersection between said paths within said band consider fill modes of said ooo: paths. 11. Apparatus as claimed in claim 10 wherein, for an inclusive render mode, the means for determining intersection between said paths along said upper border of said band further includes means for determining an intersection between said paths and 551269.doc -17- borders of a bandline row, the bandline row being the row that contains said upper border of said band. 12. Apparatus as claimed in any one of claims 7 to 11, wherein said bands are horizontal and coordinates of borders of said bands being the vertical coordinates of start points and end points each of said spline segments of both said polygons, with repeated coordinates removed. 13. Apparatus as claimed in any one of claims 7 to 12, wherein said spline segments are straight-line segments. 14. A method as claimed in any one of claims 1 to 6, wherein said spline segments are straight-line segments. 15. A method of determining whether two or more paths intersect, said method being substantially as described herein with reference to the accompanying drawings. 16. Apparatus for determining whether two or more paths intersect, said apparatus being substantially as described herein with reference to the accompanying 0 drawings. Dated this 27th day of August 2002 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant Spruson Ferguson 551269.doc