AU2004237873A1 - State table optimization in expression tree based compositing - Google Patents

Description

I

S&FRef: 702810

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3chome, Ohta-ku, Tokyo, 146, Japan Kevin John Moore Timothy Merrick Long Marija Herceg Kok Tjoan Lie Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) State table optimization in expression tree based compositing ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU 2003907200 [32] Application Date 23 Dec 2003 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c STATE TABLE OPTIMIZATION IN EXPRESSION TREE SBASED COMPOSITING _FIELD OF THE INVENTION The present invention relates generally to rendering graphic object based images.

00 5 In particular, the present invention relates to the management of a state table when t"rendering a page described by an expression tree.

SBACKGROUND

When a computer application provides data to a device for printing and/or display, an intermediate description of the page is often given to device driver software in a page description language, which provides descriptions of graphic objects to be rendered onto the page or display. This contrasts some arrangements where raster image data is generated directly and transmitted for printing or display. Examples of page description languages include PostScript and PCL. Equivalently, a set of descriptions of graphic objects may be provided in function calls to a graphics interface, such as the Microsoft Windows GDI, or Unix's X- 11. The page image is typically rendered for printing and/or display by an object-based graphics system, or a raster image processor

(RIP).

Most object-based graphics systems utilize a large volume of memory, known to the art as a frame store or a page buffer, to hold a pixel-based image data representation of the page or screen for subsequent printing and/or display. Typically, the outlines of the graphic objects are calculated, filled with colour values and written into the frame store.

For two-dimensional graphics, objects that appear in front of other objects are simply written into the frame store after the background objects, thereby replacing the background on a pixel by pixel basis. This is commonly known to the art as "Painter's algorithm". Objects are considered in priority order, from the rearmost object to the 702810.doc O foremost object, and typically, each object is rasterized in scanline order and pixels are Swritten to the frame store in sequential runs along each scanline. Some graphics Sinterfaces allow a logical or arithmetic operation to be specified and performed between one or more graphics objects and the already rendered pixels in the frame buffer. In these cases the rendering principle remains the same: objects (or groups of objects) are 00 rasterized in scanline order, and the result of the specified operation is calculated and written to the frame store in sequential runs along each scanline.

SThere are essentially two problems with this technique. The first is that it requires fast random access to all of the pixels in the frame store. This is because each new object could affect any pixel in the frame store. For this reason, the frame store is normally kept in semiconductor random access memory (RAM). For high-resolution colour printers the amount of RAM required is very large, typically in excess of 100 Mbytes, which is costly and difficult to run at high speed. The second problem is that many pixels, which are painted (rendered), are over-painted (re-rendered) by later objects.

Painting these pixels with the earlier objects is a waste of time.

One method for overcoming the large frame-store problem is the use of "banding". When banding is used, only part of the frame store exists in memory at any one time. All of the objects to be drawn are retained in a "display list", which is an internal representation of the information required to draw the objects on the page. The display list is considered in object order as above, and only those pixel operations which fall within the fraction of the page which is held in the band are actually performed. After all objects in the display list have been drawn, the band is sent to the printer (or to intermediate storage) and the process is repeated for the next band of the page. There are some penalties with this technique, however. For example, the objects being drawn must be reconsidered many times, once for each band. As the number of bands increases, so 702810.doc does the repetitious examination of the objects requiring rendering. Also, the technique (Ni o of banding does not solve the problem of the cost of over-painting.

Some other graphic systems consider the image in scan line order. Again, all of the objects on the page are retained in a display list. On each scanline the objects which intersect that scanline are then considered in priority order and for each object, spans of 00 pixels between the intersection points of the object edges with the scanline are filled in a N line store. Although this technique overcomes the large frame store problem, it still suffers from the over-painting problem.

Other graphic systems utilise pixel-sequential rendering to overcome both the large frame store problem and the over-painting problem. In these systems, each pixel is generated in raster order. Again, all objects to be drawn are retained in a display list. On each scan line, the edges of objects, which intersect that scanline, are held in increasing order of their intersection with the scan line. These points of intersection, or edge crossings, are considered in turn, and used to toggle an array of fields that indicate the activity of the objects in the display list. There is one activity field for each object painting operation that is of interest on the scan line. There is also a field to indicate operations that do not require previously generated data. Between each pair of edges considered, the colour data for each pixel, which lies between the first edge and the second edge, is generated by using a priority encoder on the activity flags to determine which operations are required to generate the colour, and performing only those operations for the span of pixels between the two edges. In preparation for the next scanline, the coordinate of intersection of each edge is updated in accordance with the nature of each edge, and the edges are sorted into increasing order of intersection with that scanline. Any new edges are also merged into the list of edges.

702810.doc -4- O Graphic systems which use pixel-sequential rendering have significant O advantages in that there is no frame store or line store, no unnecessary over-painting, and Sthe object priorities are dealt with in constant order time by the priority encoder, rather than in order N time, where N is the number of priorities. An example of such a pixel- (f 5 sequential renderer is described in US Patent No. 6,483,519, "Processing Graphic Objects 00 0 for fast rasterised rendering" issued to Long et al on 19 November 2002.

SA difficulty encountered in the pixel-sequential system of the aforementioned SUS Patent is that the operations to be performed when compositing objects onto the page may depend on the activity of other objects in the display list. Such dependencies must be taken into account when objects become activated, in order that the operations performed by all objects affected by the activated object are maintained correctly. This can involve many changes to objects as the activation propagates through the display list.

SUMMARY

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

According to one aspect of the invention, there is provided a method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; 702810 .doc identifying as contributing levels those active levels that are not masked, wherein said o identifying step considers the levels of the description in sequence from lower levels to higher levels.

According to a second aspect of the invention there is provided an apparatus for identifying contributing objects on a scanline of an object-based image to be rendered, 00 said apparatus comprising means for storing a hierarchical description of said image, said (Ni N description being arranged in a plurality of levels from a lowest level to a highest level, Seach level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; means for determining levels that are active for a range of pixels on the scanline; means for updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; means for masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; means for identifying as contributing levels those active levels that are not masked, wherein said means for identifying considers the levels of the description in sequence from lower levels to higher levels.

According to a further aspect of the invention there is provided a system for identifying contributing objects on a scanline of an object-based image to be rendered, said system comprising: a storage unit for storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; a processing circuit for determining levels that are active for a range of pixels on the scanline; a processing circuit for updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; a 702810.doc masking circuit for masking the levels in a branch if the counter of the ancestor level of o the branch is non-zero but said ancestor level does not contribute to said range of pixels; and a processor for identifying as contributing levels those active levels that are not masked, wherein said processor considers the levels of the description in sequence from lower levels to higher levels.

00 According to a further aspect of the invention there is provided a computer program (Ni comprising machine-readable program code for controlling the operation of a data processing apparatus on which the program executes to perform a method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of: storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; identifying as contributing levels those active levels that are not masked, wherein said identifying step considers the levels of the description in sequence from lower levels to higher levels.

According to a further aspect of the invention there is provided a computer program product comprising machine-readable program code recorded on a machine-readable recording medium, for controlling the operation of a data processing apparatus on which the program code executes to perform a method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of 702810.doc -7- O storing a hierarchical description of said image, said description being arranged in a o plurality of levels from a lowest level to a highest level, each level being descriptive of a Scorresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; updating said counter, for an 00 ancestor level of each said branch, to indicate the number of active levels in said branch; (Ni N masking the levels in a branch if the counter of the ancestor level of the branch is non- Szero but said ancestor level does not contribute to said range of pixels; identifying as contributing levels those active levels that are not masked, wherein said identifying step considers the levels of the description in sequence from lower levels to higher levels.

Other aspects of the invention are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the present invention will now be described with reference to the drawings, in which: Fig. 1 is a schematic block diagram representation of a computer system incorporating a rendering arrangement; Fig. 2 is a block diagram showing the functional data flow of the rendering arrangement; Fig. 3 is a schematic block diagram representation of the pixel sequential rendering apparatus of Fig. 2 and associated display list and temporary stores; Fig. 4 is a schematic functional representation of the edge processing module of Fig. 3; Fig. 5 is a schematic functional representation of the priority determination module of Fig. 3; 702810 .doc -8- O Fig. 6 is a schematic functional representation of the fill colour determination o module of Fig. 3; SFigs. 7A to 7C illustrate pixel combinations between source and destination; Fig. 8A illustrates a two-object image used as an example for explaining the operation of the rendering arrangement; 00 Fig. 8B shows a table of a number of edge records of the two-object image (Ni shown in Fig. 8A; SFigs. 9A and 9B illustrate the vector edges of the objects of Fig. 8A; Fig. 10 illustrates the rendering of a number of scan lines of the image of Fig.

8A; Fig. 11 depicts the arrangement of an edge record for the image of Fig. 8A; Fig. 12A depicts the format of an active edge record created by the edge processing module 400 of Fig. 4; Fig. 12B depicts the arrangement of the edge records used in the edge processing module 400 of Fig.4; Figs. 12C to 12J illustrate the edge update routine implemented by the arrangement of Fig. 4 for the example of Fig. 8A; Figs. 13A and 13B illustrate the odd-even and non-zero winding fill rules; Figs. 14A to 14E illustrate how large changes in X coordinates contribute to spill conditions and how they are handled; Figs. 15A to 15E illustrate the priority filling routine implemented by the arrangement of Fig. Figs. 16A to 16D provide a comparison between two prior art edge description formats and that used in the described apparatus; 702810.doc -9- Figs. 1 7A and 1 7B show a simple compositing expression illustrated as an o expression tree and a corresponding depiction; Fig. 17C shows an example of an expression tree; Fig. 18 depicts the priority properties and status table of the priority determination module of Fig. 3; 00 Fig. 19 shows a table of a number of raster operations; N Figs. 20A and 20B show a table of the principal compositing operations and their corresponding raster operations and opacity flags; Fig. 21 depicts the result of a number of compositing operations;, Fig. 22A shows a series of fill priority messages generated by the priority determination module 500; Fig. 22B shows a series of colour composite messages generated by the fill colour determnination module 600; Fig. 23 is a schematic functional representation of one arrangement of the pixel compositing module of Fig. 3; Figs. 24A 24D show the operation performied on the stack for each of the various stack operation commands in the Pixel Compositing Module 700 of Fig. 3; Fig. 25A shows an example of two graphical objects produced by a compositing operation; Fig. 25B illustrates a pixel from the example of Fig. Fig. 26 shows an example of a right-biased expression tree; Figs. 27A and 27B illustrate a portion of an expression tree having an added PUSH operation; Fig. 28 depicts fields of a single level of a level activation table according to the present invention; 70281 0.doc Fig. 29A depicts an example of an expression tree; o Fig. 29B depicts the expression tree of Fig. 29A expressed in a tabular form; SFig. 30A shows a flow diagram of a procedure to maintain counters in the table of Fig. 28; 5 Fig. 30B shows a flow diagram of a procedure for the case when a level of the 00 r, table of Fig. 28 is activated; (Ni Fig. 30C shows a flow diagram for the case when a level of the table is Sdeactivated; Fig. 31A shows a flow diagram for the case when a counter of the table of Fig.

28 is incremented; Fig. 31B shows a flow diagram for the case when a counter is decremented; Fig. 32 illustrates the rendering of a scanline in the example of Figs. 29A and B; Fig. 33 depicts a circuit for maintaining counters in the table of Fig. 28; Fig. 34 depicts a circuit for maintaining mask counters in the table of Fig. 28; Fig. 35 depicts a circuit for masking left branches in the table of Fig. 28; and Fig. 36 depicts a flow diagram of a procedure whereby the arrangement of Fig. generates PIXEL AT LEVEL commands.

DETAILED DESCRIPTION INCLUDING BEST MODE Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

For a better understanding of the pixel sequential rendering system 1, a brief overview of the system is first undertaken in Section 1.0. Then follows a brief discussion 702810.doc -11- O in Section 2.0 of the driver software for interfacing between a third party software o application and the pixel sequential rendering apparatus 20 of the system. A brief Soverview of the pixel sequential rendering apparatus 20 is then discussed in Section As will become apparent, the pixel sequential rendering apparatus 20 includes an 5 instruction execution module 300; an edge tracking module 400; a priority determination 00 module 500; a fill colour determination module 600; a pixel compositing module 700; and (Ni a pixel output module 800. A brief overview of these modules is described in Sections 3.1 to 3.6.

The general principles of the invention have application in the optimization of processing associated with the activation of objects. This is realised in the preferred system in the level activation module 500 as described in more detail in Section PIXEL SEQUENTIAL RENDERING SYSTEM Fig. 1 illustrates schematically a computer system 1 configured for rendering and presentation of computer graphic object images. The system includes a host processor 2 associated with system random access memory (RAM) 3, which may include a nonvolatile hard disk drive or similar device 5 and volatile, semiconductor RAM 4. The system 1 also includes a system read-only memory (ROM) 6 typically founded upon semiconductor ROM 7 and which in many cases may be supplemented by compact disk devices (CD ROM) 8. The system 1 may also incorporate some means 10 for displaying images, such as a video display unit (VDU) or a printer, both, which operate in raster fashion.

The above-described components of the system 1 are interconnected via a bus system 9 and are operable in a normal operating mode of computer systems well known in the art, such as IBM PC/AT type personal computers and arrangements evolved therefrom, Sun Sparcstations and the like.

702810 .doc 12- Also seen in Fig. 1, a pixel sequential rendering apparatus 20 (or renderer) Sconnects to the bus 9, and is configured for the sequential rendering ofpixel-based images derived from graphic object-based descriptions supplied with instructions and data from the system 1 via the bus 9. The apparatus 20 may utilise the system RAM 3 for the rendering of object descriptions although preferably the rendering apparatus 20 may have 00 0- associated therewith a dedicated rendering store arrangement 30, typically formed of semiconductor RAM.

Image rendering operates generally speaking in the following manner. A render job to be rendered is given to the driver software by third party software for supply to the pixel sequential renderer 20. The render job is typically in a page description language or in a sequence of function calls to a standard graphics application program interface (API), which defines an image comprising objects placed on a page from a rearmost object to a foremost object to be composited in a manner defined by the render job. The driver software converts the render job to an intermediate render job, which is then fed to the pixel sequential renderer 20. The pixel sequential renderer 20 generates the colour and opacity for the pixels one at a time in raster scan order. At any pixel currently being scanned and processed, the pixel sequential renderer 20 composites only those exposed objects that are active at the currently scanned pixel. The pixel sequential renderer determines that an object is active at a currently scanned pixel if that pixel lies within the boundary of the object. The pixel sequential renderer 20 achieves this by reference to a fill counter associated with that object. The fill counter keeps a running fill count that indicates whether the pixel lies within the boundary of the object. When the pixel sequential renderer 20 encounters an edge associated with the object it increments or decrements the fill count depending upon the direction of the edge. The renderer 20 is then able to determine whether the current pixel is within the boundary of the object 702810.doc -13 depending upon the fill count and a predetermined winding count rule. The renderer Sdetermines whether an active object is exposed with reference to a flag associated with that object. This flag associated with an object indicates whether or not the object obscures lower order objects. That is, this flag indicates whether the object is partially transparent, and in which case the lower order active objects will thus make a contribution 00 to the colour and opacity of the current pixel. Otherwise, this flag indicates that the (Ni object is opaque in which case active lower order objects will not make any contribution to the colour and opacity of the currently scanned pixel. The pixel sequential renderer determines that an object is exposed if it is the uppermost active object, or if all the active objects above the object have their corresponding flags set to transparent. The renderer then composites these exposed active objects to determine and output the colour and opacity for the currently scanned pixel.

The driver software, in response to the page, also extracts edge information defining the edges of the objects for feeding to the edge tracking module. The driver software also generates a linearised table of priority properties and status information (herein called the level activation table) of the expression tree of the objects and their compositing operations which is fed to the priority determination module. The level activation table contains one record for each object on the page. In addition, each record contains a field for storing a pointer to an address for the fill of the corresponding object in a fill table. This fill table is also generated by the driver software and contains the fill for the corresponding objects, and is fed to the fill determination module. The level activation table together with the fill table is devoid of any edge information and effectively represent the objects, where the objects are infinitively extending. The edge information is fed to the edge tracking module, which determines, for each pixel in raster scan order, the edges of any objects that intersect a currently scanned pixel. The edge 702810.doc -14- O processing module passes this information onto the priority determination module. Each o record of the level activation table contains a counter, which maintains a fill count associated with the corresponding object of the record. The priority determination module processes each pixel in a raster scan order. Initially, the fill counts associated 5 with all the objects are zero, and so all objects are inactive. The priority determination 00 0 module continues processing each pixel until it encounters an edge intersecting that pixel.

(Ni The priority determination module updates the fill count associated with the object of that Sedge, and so that object becomes active. The priority determination continues in this fashion updating the fill count of the objects and so activating and de-activating the objects. The priority determination module also determines whether these active objects are exposed or not, and consequently whether they make a contribution to the currently scanned pixel. In the event that they do, the pixel determination module generates a series of messages which ultimately instructs the pixel compositing module to composite the colour and opacity for these exposed active objects in accordance with the compositing operations specified for these objects in the level activation so as to generate the resultant colour and opacity for the currently scanned pixel. These series of messages do not at that time actually contain the colour and opacity for that object but rather an address to the fill table, which the fill determination module uses to determine the colour and opacity of the object.

For ease of explanation the location (ie: priority level or z-order) of the object in the order of the objects from the rearmost object to the foremost is herein referred to as the object's priority. Preferably, a number of non-overlapping objects that have the same fill and compositing operation, and that form a contiguous sequence in the order of the objects, may be designated as having the same priority. Most often, only one priority level is required per object. However, some objects may require several instructions, and 702810 .doc O thus the object may require several priority levels. For example, a character with a colour o fill may be represented by, a bounding box on a first level having the colour fill, a Sone-bit bitmap which provides the shape of the character on a second level, and the same bounding box on a third level having the colour fill, where the levels are composited together xor Page) and S) xor B to produce the colour character. For 00 fundamental objects, there is a one-to-one relationship with priority levels.

The pixel sequential renderer 20 also utilises clip objects to modify the shape of Sother objects. The renderer 20 maintains an associated clip count for the clip in a somewhat similar fashion to the fill count to determine whether the current pixel is within the clip region.

SOFTWARE DRIVER A software program, hereafter referred to as the driver, is loaded and executed on the host processor 2 for generating instructions and data for the pixel-sequential graphics rendering apparatus 20, from data provided to the driver by a third-party application. The third-party application may provide data in the form of a standard language description of the objects to be drawn on the page, such as PostScript and PCL, or in the form of function calls to the driver through a standard software interface, such as the Windows GDI or X-11.

The driver software separates the data associated with an object, supplied by the third-party application, into data about the edges of the object, any operation or operations associated with painting the object onto the page, and the colour and opacity with which to fill pixels which fall inside the edges of the object.

The driver software partitions the edges of each object into edges which are monotonic increasing in the Y-direction, and then divides each partitioned edge of the object into segments of a form suitable for the edge module described below. Partitioned 702810.doc -16- O edges are sorted by the X-value of their starting positions and then by Y. Groups of edges o starting at the same Y-value remain sorted by X-value, and may be concatenated together to form a new edge list, suitable for reading in by the edge module when rendering reaches that Y-value.

The driver software sorts the operations, associated with painting objects, into 00 priority order, and generates instructions to load the data structure associated with the e¢3 (priority determination module (described below). This structure includes a field for the Sfill rule, which describes the topology of how each object is activated by edges, a field for the type of fill which is associated with the object being painted, and a field to identify whether data on levels below the current object is required by the operation. There is also a field, herein called clip count, that identifies an object as a clipping object, that is, as an object which is not, itself, filled, but which enables or disables filling of other objects on the page.

The driver software also prepares a data structure (the fill table) describing how to fill objects. The fill table is indexed by the data structure in the priority determination module. This allows several levels in the priority determination module to refer to the same fill data structure.

The driver software assembles the aforementioned data into a job containing instructions for loading the data and rendering pixels, in a form that can be read by the rendering system, and transfers the assembled job to the rendering system. This may be performed using one of several methods known to the art, depending on the configuration of the rendering system and its memory.

PIXEL SEQUENTIAL RENDERING APPARATUS Referring now to Fig. 2, a functional data flow diagram of the rendering process is shown. The functional flow diagram of Fig. 2 commences with an object graphic 702810 .doc -17- O description 11 which is used to describe those parameters of graphic objects in a fashion Sappropriate to be generated by the host processor 2 and/or, where appropriate, stored Swithin the system RAM 3 or derived from the system ROM 6, and which may be interpreted by the pixel sequential rendering apparatus 20 to render therefrom pixel-based 5 images. For example, the object graphic description 11 may incorporate objects with 00 edges in a number of formats including straight edges (simple vectors) that traverse from (Ni N one point on the display to another, or an orthogonal edge format where a two- Sdimensional object is defined by a plurality of edges including orthogonal lines. Further formats, where objects are defined by continuous curves are also appropriate and these can include quadratic polynomial fragments where a single curve may be described by a number of parameters which enable a quadratic based curve to be rendered in a single output space without the need to perform multiplications. Further data formats such as cubic splines and the like may also be used. An object may contain a mixture of many different edge types. Typically, common to all formats are identifiers for the start and end of each line (whether straight or curved) and typically, these are identified by a scan line number thus defining a specific output space in which the curve may be rendered.

For example, Fig. 16A shows a prior art edge description of an edge 600 that is required to be divided into two segments 601 and 602 in order for the segments to be adequately described and rendered. This arises because the prior art edge description, whilst being simply calculated through a quadratic expression, could not accommodate an inflexion point 604. Thus the edge 600 was dealt with as two separate edges having end points 603 and 604, and 604 and 605 respectively. Fig. 16B shows a cubic spline 610 that is described by endpoints 611 and 612, and control points 613 and 614. This format requires calculation of a cubic polynomial for render purposes and thus is expensive of computational time.

702810 .doc -18 O Figs. 16C and 16D show examples of edges applicable to the described o arrangement. An edge is considered as a single entity and if necessary, is partitioned to Sdelineate sections of the edge that may be described in different formats, a specific goal of which is to ensure a minimum level of complexity for the description of each section.

In Fig. 16C, a single edge 620 is illustrated spanning between scanlines A and 00 M. An edge is described by a number of parameters including start_x, start_y, one or (Ni N more segment descriptions that include an address that points to the next segment in the edge, and a finish segment used to terminate the edge. Preferably, the edge 620 may be described as having three step segments, a vector segment, and a quadratic segment. A step segment is simply defined as having a x-step value and a y-step value. For the three step segments illustrated, the segment descriptions are and Note that the x-step value is signed thereby indicating the direction of the step, whilst the y-step value is unsigned as such is always in a raster scan direction of increasing scanline value.

The next segment is a vector segment which typically requires parameters startx starty num ofscanlines (NY) and slope In this example, because the vector segment is an intermediate segment of the edge 620, the start_x and start_y may be omitted because such arise from the preceding segment(s). The parameter numof scanlines (NY) indicates the number of scanlines the vector segment lasts. The slope value (DX) is signed and is added to the x-value of a preceding scanline to give the x-value of the current scanline, and in the illustrated case, DX The next segment is a quadratic segment which has a structure corresponding to that of the vector segment, but also a second order value (DDX) which is also signed and is added to DX to alter the slope of the segment.

Fig. 16D shows an example of a cubic curve which includes a description corresponding to the quadratic segment save for the addition of a signed third-order value 70281 O.doc -19- O (DDDX), which is added to DDX to vary the rate of change of slope of the segment.

o Many other orders may also be implemented.

SIt will be apparent from the above that the ability to handle plural data formats describing edge segments allows for simplification of edge descriptions and evaluation, e¢ 5 without reliance on complex and computationally expensive mathematical operations. In 00 contrast, in the prior art system of Fig. 16A, all edges, whether orthogonal, vector or N quadratic were required to be described by the quadratic form.

0 The operation of the rendering arrangement will be described with reference to the simple example of rendering an image 78 shown in Fig. 8 which is seen to include two graphical objects, in particular, a partly transparent blue-coloured triangle rendered on top of and thereby partly obscuring an opaque red coloured rectangle 90. As seen, the rectangle 90 includes side edges 92, 94, 96 and 98 defined between various pixel positions and scan line positions Because the edges 96 and 98 are formed upon the scan lines (and thus parallel therewith), the actual object description of the rectangle 90 can be based solely upon the side edges 92 and 94, such as seen in Fig. 9A. In this connection, edge 92 commences at pixel location (40,35) and extends in a raster direction down the screen to terminate at pixel position (40,105). Similarly, the edge 94 extends from pixel position (160,35) to position (160,105). The horizontal portions of the rectangular graphic object 90 may be obtained merely by scanning from the edge 92 to the edge 94 in a rasterised fashion.

The blue triangular object 80 however is defined by three object edges 82, 84 and 86, each seen as vectors that define the vertices of the triangle. Edges 82 and 84 are seen to commence at pixel location (100,20) and extend respectively to pixel locations (170,90) and (30,90). Edge 86 extends between those two pixel locations in a traditional rasterised direction of left to right. In this specific example because the edge 86 is 702810.doc O horizontal like the edges 96 and 98 mentioned above, it is not essential that the edge 86 be o defined. In addition to the starting and ending pixel locations used to describe the edges S82 and 84, each of these edges will have associated therewith the slope value in this case +1 and-1 respectively.

Returning to Fig. 2, having identified the data necessary to describe the graphic 00 objects to the rendered, the graphic system 1 then performs a display list generation step 12.

SThe display list generation 12 is preferably implemented as a software driver executing on the host processor 2 with attached ROM 6 and RAM 3. The display list generation 12 converts an object graphics description, expressed in any one or more of the well known graphic description languages, graphic library calls, or any other application specific format, into a display list. The display list is typically written into a display list store 13, generally formed within the RAM 4 but which may alternatively be formed within the temporary rendering stores 30. As seen in Fig. 3, the display list store 13 can include a number of components, one being an instruction stream 14, another being edge information 15 and where appropriate, raster image pixel data 16.

The instruction stream 14 includes code interpretable as instructions to be read by the pixel sequential rendering apparatus 20 to render the specific graphic objects desired in any specific image. For the example of the image shown in Fig. 8, the instruction stream 14 could be of the form of: render (nothing) to scan line at scan line 20 add two blue edges 82 and 84; render to scan line at scan line 35 add two red edges 92 and 94; and render to completion.

702810.doc -21- O Similarly, the edge information 15 for the example of Fig. 8 may include the o following: edge 84 commences at pixel position 100, edge 82 commences at pixel position 100; 5 (ii) edge 92 commences at pixel position 40, edge 94 commences at pixel 00 position 160; (iii) edge 84 runs for 70 scan lines, edge 82 runs for 70 scanlines; S(iv) edge 84 has slope edge 82 has slope +1; edge 92 has slope 0, edge 94 has slope 0.

(vi) edges 92 and 94 each run for 70 scanlines.

It will be appreciated from the above example of the instruction stream 14 and edge information 15 and the manner in which each are expressed, that in the image 78 of Fig. 8, the pixel position and the scanline value define a single 2-dimensional output space in which the image 78 is rendered. Other output space configurations however can be realised using the principles of the present disclosure.

Fig. 8 includes no raster image pixel data and hence none need be stored in the store portion 16 of the display list 13, although this feature will be described later.

The display list store 13 is read by a pixel sequential rendering apparatus The pixel sequential rendering apparatus 20 is typically implemented as an integrated circuit and converts the display list into a stream of raster pixels which can be forwarded to another device, for example, a printer, a display, or a memory store.

Although the pixel sequential rendering apparatus 20 is described as an integrated circuit, it may be implemented as an equivalent software module executing on a general purpose processing unit, such as the host processor 2.

702810.doc 22 o Fig. 3 shows the configuration of the pixel sequential rendering apparatus 20, the display list store 13 and the temporary rendering stores 30. The processing stages 22 of Sthe pixel-sequential rendering apparatus 20 include an instruction executor 300, an edge processing module 400, a priority determination module 500, a fill colour determination 5 module 600, a pixel compositing module 700, and a pixel output module 800. The 00 processing operations use the temporary stores 30 which, as noted above, may share the same device (eg. magnetic disk or semiconductor RAM) as the display list store 13, or Smay be implemented as individual stores for reasons of speed optimisation. The edge.

processing module 400 uses an edge record store 32 to hold edge information which is carried forward from scan-line to scan-line. The priority determination module 500 uses a priority properties and status table 34 to hold information about each priority, and the current state of each priority with respect to edge crossings while a scan-line is being rendered. The fill colour determination module 600 uses a fill data table 36 to hold information required to determine the fill colour of a particular priority at a particular position. The pixel compositing module 700 uses a pixel compositing stack 38 to hold intermediate results during the determination of an output pixel that requires the colours from multiple priorities to determine its value.

The display list store 13 and the other stores 32-38 detailed above may be implemented in RAM or any other data storage technology.

The processing steps shown in the arrangement of Fig. 3 take the form of a processing pipeline 22. In this case, the modules of the pipeline may execute simultaneously on different portions of image data in parallel, with messages passed between them as described below. In another arrangement, each message described below may take the form of a synchronous transfer of control to a downstream module, 702810.doc 23 with upstream processing suspended until the downstream module completes the O processing of the message.

3.1 INSTRUCTION EXECUTOR The instruction executor 300 reads and processes instructions from the instruction stream 14 and formats the instructions into messages that are transferred via an 00 output 398 to the other modules 400, 500, 550, 600 and 700 within the pipeline 22.

Preferably, the instruction stream 14 may include the following instructions: SLOAD PRIORITY PROPERTIES: This instruction is associated with data to be loaded into the priority properties and status table 34, and an address in that table to which the data is to be loaded. When this instruction is encountered by the instruction executor 300, the instruction executor 300 issues a message for the storage of the data in the specified location of the priority properties and status table 34. This may be accomplished by formatting a message containing this data and passing it down the processing pipeline 22 to the priority determination module 500 which performs the store operation.

LOAD FILL DATA: This instruction is associated with fill data associated with an object to be loaded into the fill data table 36, and an address in that table to which the data is to be loaded. When this instruction is encountered by the instruction executor 300, the instruction executor 300 issues a message for the storage of the data at the specified address of the fill data table 36. This may be accomplished by formatting a message containing this data and passing it down the processing pipeline 22 to the fill colour determination module which performs the store operation.

LOAD NEW EDGES AND RENDER: This instruction is associated with an address in the display list store 13 of new edges 15 which are to be introduced into the rendering process when a next scanline is rendered. When this instruction is encountered 70281 O.doc -24- O by the instruction executor 300, the instruction executor 300 formats a message o containing this data and passes it to the edge processing module 400. The edge Sprocessing module 400 stores the address of the new edges in the edge record store 32.

The edges at the specified address are sorted on their initial scanline intersection coordinate before the next scanline is rendered. In one arrangement, they are sorted by 00 the display list generation process 12. In another arrangement, they are sorted by the (Ni pixel-sequential rendering apparatus SET SCANLINE LENGTH: This instruction is associated with a number of pixels which are to be produced in each rendered scanline. When this instruction is encountered by the instruction executor 300, the instruction executor 300 passes the value to the edge processing module 400 and the pixel compositing module 700.

SETOPACITYMODE: This instruction is associated with a flag, which indicates whether pixel compositing operations will use an opacity channel, also known in the art as an alpha or transparency channel. When this instruction is encountered by the instruction executor 300, the instruction executor 300 passes the flag value in the pixel compositing module 700.

SET_BUF: This instruction sets the address of external memory buffers used by the pixel sequential rendering apparatus 20. Preferably, at least the input, output and spill buffers of the edge processing module 400 are stored in external memory. Level and fill tables may also be constructed in memory and referenced with a SETBUF.

The instruction executor 300 is typically formed by a microcode state machine that maps instructions and decodes them into pipeline operations for passing to the various modules. A corresponding software process may alternatively be used.

3.2 EDGE PROCESSING MODULE 702810.doc O The operation of the edge processing module 400 during a scanline render o operation will now be described with reference to Fig. 4. The initial conditions for the Srendering of a scanline is the availability of three lists of edge records. Any or all of these lists may be empty. These lists are a new edge list 402, obtained from the edge information 15 and which contains new edges as set by the 00 LOAD_NEW_EDGES_AND_RENDER instruction, a main edge list 404 which contains (Ni edge records carried forward from the previous scanline, and a spill edge list 406 which Salso contains edge records carried forward from the previous scanline.

Turning now to Fig. 12A, there is shown the data format of such an edge record, which may include: a current scanline intersection coordinate (referred to here as the X coordinate), (ii) a count (referred to herein as NY) of how many scanlines a current segment of this edge will last for (in some arrangements this may be represented as a Y limit), (iii) a value to be added to the X coordinate of this edge record after each scanline (referred to here as the DX), (iv) a priority level number or an index to a list of priority numbers, an address (addr) of a next edge segment in the list; and (vi) a number of flags, marked p, o, u, c and d. The flag d determines whether the edge affects the clipping counter or the fill counter. The flag u determines whether the fill counter is incremented or decremented by the edge. The remaining flags are not significant in the rendering process and need not be described.

Such a data format may accommodate vectors, and orthogonally arranged edges.

The format may also include a further parameter herein called DDX, which is a value to 702810 .doc -26- O be added to the DX value of this edge record after each scanline. The latter enables the o rendering of edges describing quadratic curves. The addition of further parameters, SDDDX for example, may allow such an arrangement to accommodate cubic curves. In some applications, such as cubic Bezier spline, a 6-order polynomial (ie: up to M€3 5 DDDDDDX) may be required. The flag indicates whether a winding count is to be r- 00 incremented or decremented by an edge. The winding count is stored in a fill counter and N is used to determine whether a currently scanned pixel is inside or outside the object in Squestion.

In the example of the edges 84 and 94 of Fig. 8A, the corresponding edge records at scanline 20 could read as shown in the Table of Fig. 8B.

In this description, coordinates which step from pixel to pixel along a scanline being generated by the rendering process will be referred to as X coordinates, and coordinates which step from scanline to scanline will be referred to as Y coordinates.

Preferably, each edge list contains zero or more records placed contiguously in memory.

Other storage arrangements, including the use of pointer chains, are also possible. The records in each of the three lists 402, 404 and 406 are arranged in order of scanline intersection, this being the X coordinate. This is typically obtained by a sorting process, initially managed by an edge input module 408 which receives messages, including edge information, from the instruction executor 300. It is possible to relax the sort to only regard the integral portion of each scanline intersection coordinate as significant. It is also possible to relax the sort further by only regarding each scanline intersection coordinate, clamped to the minimum and maximum X coordinates which are being produced by the current rendering process. Where appropriate, the edge input module 408 relays messages to modules 500, 600 and 700 downstream in the pipeline 22 via an output 498.

702810.doc -27- O The edge input module 408 maintains references into, and receives edge data o from, each of the three lists 402, 404, and 406. Each of these references is initialised to Srefer to the first edge in each list at the start of processing of a scanline. Thereafter, the edge input module 408 selects an edge record from one of the three referenced edge 5 records such that the record selected is the one with the least X coordinate out of the three 00 0 referenced records. If two or more of the X-records are equal, each is processed in any (Ni order and the corresponding edge crossings output in the following fashion. The Sreference, which was used to select that record, is then advanced to the next record in that list. The edge just selected is formatted into a message and sent to an edge update module 410. Also, certain fields of the edge, in particular the current X, the priority numbers, and the direction flag, are formatted into a message which is forwarded to the priority determination module 500 via an output 498 of the edge processing module 400.

Arrangements that use more or fewer lists than those described here are also possible.

Upon receipt of an edge, the edge update module 410 decrements the count of how many scanlines a current segment will last. If that count has reached zero, a new segment is read from the address indicated by the next segment address. A segment preferably specifies: a value to add to the current X coordinate immediately the segment is read, (ii) a new DX value for the edge, (iii) a new DDX value for the edge, and (iv) a new count of how many scanlines the new segment will last.

If there is no next segment available at the indicated address, no further processing is performed on that edge. Otherwise, the edge update module 410 calculates the X coordinate for the next scanline for the edge. This typically would involve taking 70281 O.doc -28- O the current X coordinate and adding to it the DX value. The DX may have the DDX o value added to it, as appropriate for the type of edge being handled. The edge is then Swritten into any available free slot in an edge pool 412, which is an array of two or more edge records. If there is no free slot, the edge update module 410 waits for a slot to (f 5 become available. Once the edge record is written into the edge pool 412, the edge 00 0 update module 410 signals via a line 416 to an edge output module 414 that a new edge (Ni has been added to the edge pool 412.

SAs an initial condition for the rendering of a scanline, the edge output module 414 has references to each of a next main edge list 404' and a next spill edge list 406'.

Each of these references is initialised to the location where the, initially empty, lists 404' and 406' may be built up. Upon receipt of the signal 416 indicating that an edge has been added to the edge pool 412, the edge output module 414 determines whether or not the edge just added has a lesser X coordinate than the edge last written to the next main edge list 404' (if any). If this is true, a "spill" is said to have occurred because the edge cannot be appended to the main edge list 404 without violating its ordering criteria. When a spill occurs, the edge is inserted into the next spill edge list 406', preferably in a manner that maintains a sorted next spill edge list 406'. For example this may be achieved using a insertion sorting routine. In some arrangements the spills may be triggered by other conditions, such as excessively large X coordinates.

If the edge added to the edge pool 412 has an X coordinate greater than or equal to the edge last written to the next main edge list 404' (if any), and there are no free slots available in the edge pool 412, the edge output module 414 selects the edge from the edge pool 412 which has the least X coordinate, and appends that edge to the next main edge list 404', extending it in the process. The slot in the edge pool 412 that was occupied by that edge is then marked as free.

702810.doc -29- O Once the edge input module 408 has read and forwarded all edges from all three o of its input lists 402, 404 and 406, it formats a message which indicates that the end of Sscanline has been reached and sends the message to both the priority determination module 500 and the edge update module 410. Upon receipt of that message, the edge update module 410 waits for any processing it is currently performing to complete, then 00 forwards the message to the edge output module 414. Upon receipt of the message, the N edge output module 414 writes all remaining edge records from the edge pool 412 to the Snext main edge list 404' in X order. Then, the reference to the next main edge list 404' and the main edge list 404 are exchanged between the edge input module 408 and the edge output module 414, and a similar exchange is performed for the next spill edge list 406' and the spill edge list 406. In this way the initial conditions for the following scanline are established.

Rather than sorting the next spill edge list 406' upon insertion of edge records thereto, such edge records may be merely appended to the list 406', and the list 406' sorted at the end of the scanline and before the exchange to the current spill list 406 becomes active in edge rasterisation of the next scanline.

It can be deduced from the above that edge crossing messages are sent to the priority determination module 500 in scanline and pixel order (that is, they are ordered firstly on Y and then on X) and that each edge crossing message is labelled with the priority level to which it applies.

Fig. 12A depicts a specific structure of an active edge record 418 that may be created by the edge processing module 400 when a segment of an edge is received. If the first segment of the edge is a step (orthogonal) segment, the X-value of the edge is added to a variable called "X-step" for the first segment to obtain the X position of the activated edge. Otherwise, the X-value of the edge is used. The Xstep value is obtained from the 702810 .doc O segment data of the edge and is added once to the Xedge value of the next segment to O obtain the X position of the edge record for that next segment. This means that the edges Sin the new edge record will be sorted by Xedge Xstep. The Xstep of the first segment should, therefore, be zero, in order to simplify sorting the edges. The Y-value of the first Cc 5 segment is loaded into the NY field of the active edge record 418. The DX field of the 00 active edges copied from the DX field identifier of vector or quadratic segments, and is (Ni set to zero for a step segment. A u-flag as seen in Fig. 12A is set if the segment is upwards heading (see the description relating to Fig. 13A). A d-flag is set when the edge is used as a direct clipping object, without an associated clipping level, and is applicable to closed curves. The actual priority level of the segment, or a level address is copied from the corresponding field of the new edge record into a level field in the active edge record 418. The address of the next segment in the segment list is copied from the corresponding field of the new edge record into a segment address field (segment addr) of the active edge record 418. The segment address may also be used to indicate the termination of an edge record.

It will be appreciated from Fig. 12A that other data structures are also possible, and necessary for example where polynomial implementations are used. In one alternative data structure, the 'segment addr' field is either the address of the next segment in the segment list or copied from the segments DDX value, if the segment is quadratic. In the latter case, the data structure has a q-flag which is set if the segment is a quadratic segment, and cleared otherwise. In a further variation, the segment address and the DDX field may be separated into different fields, and additional flags provided to meet alternate implementations.

Fig. 12B depicts the arrangement of the edge records described above and used in the edge processing module 400. A new active edge record 428, a current active edge 70281 O.doc -31 O record 430 and a spill active edge record 432, supplements the edge pool 412. As seen in Fig. 12B, the records 402, 404, 406, 404' and 406' are dynamically variable in size Sdepending upon the number of edges being rendered at any one time. Each record includes a limit value which, for the case of the new edge list 402, is determined by a M 5 SIZE value incorporated with the LOAD_EDGES_AND_RENDER instruction. When r"- 00 such an instruction is encountered, SIZE is checked and if non-zero, the address of the (Ni new edge record is loaded and a limit value is calculated which determines a limiting size O for each of the lists 402, 404, 406, 404' and 406'.

Although the described arrangement utilizes arrays and associated pointers for the handling of edge records, other implementations, such as linked lists for example may be used. These other implementations may be hardware or software-based, or combinations thereof.

The specific rendering of the image 78 shown in Fig. 8A will now be described with reference to scanlines 34, 35 and 36 shown in Fig. 10. In this example, the calculation of the new X coordinate for the next scanline is omitted for the purposes of clarity, with Figs. 12C to 121 illustrating the output edge crossing being derived from one of the registers 428, 430 and 432 of the edge pool 412.

Fig. 12C illustrates the state of the lists noted above at the end of rendering scanline 34 (the top portion of the semi-transparent blue triangle 80). Note that in scanline 34 there are no new edges and hence the list 402 is empty. Each of the main edge lists 404 and next main edge list 404' include only the edges 82 and 84. Each of the lists includes a corresponding pointer 434, 436, and 440 which, on completion of scanline 34, points to the next vacant record in the corresponding list. Each list also includes a limit pointer 450, denoted by an asterisk which is required to point to the 702810.doc -32- O end of the corresponding list. If linked lists were used, such would not be required as o linked lists include null pointer terminators that perform a corresponding function.

SAs noted above, at the commencement of each scanline, the next main edge list 404' and the main edge list 404 are swapped and new edges are received into the new edge list 402. The remaining lists are cleared and each of the pointers set to the first 00 member of each list. For the commencement of scanline 35, the arrangement then

C,

appears as seen in Fig. 12D. As is apparent from Fig. 12D, the records include four active Sedges which, from Fig. 10, are seen to correspond to the edges 92, 94, 84 and 82.

Referring now to Fig. 12E, when rendering starts, the first segment of the new edge record 402 is loaded into an active edge record 428 and the first active edge records of the main edge list 404 and spill edge list 406 are copied to records 430 and 432 respectively. In this example, the spill edge list 406 is empty and hence no loading takes place. The X-positions of the edges within the records 428, 430 and 432 are then compared and an edge crossing is emitted for the edge with the smallest X-position. In this case, the emitted edge is that corresponding to the edge 92 which is output together with its priority value. The pointers 434, 436 and 438 are then updated to point to the next record in the list.

The edge for which the edge crossing was emitted is then updated (in this case by adding DX 0 to its position), and buffered to the edge pool 412 which, in this example, is sized to retain three edge records. The next entry in the list from which the emitted edge arose (in this case list 402) is loaded into the corresponding record (in this case record 428). This is seen in Fig. 12F.

Further, as is apparent from Fig. 12F, a comparison between the registers 428, 430 and 432 again selects the edge with the least X-value which is output as the appropriate next edge crossing (X=85, Again, the selected output edge is updated 702810.doc -33- O and added to the edge pool 412 and all the appropriate pointers incremented. In this case, o the updated value is given by X X DX, which is evaluated as 84 85 1. Also, as d seen, the new edge pointer 434 is moved, in this case, to the end of the new edge list 402.

In Fig. 12G, the next edge identified with the lowest current X-value is again that M 5 obtained from the register 430 which is output as an edge crossing (X=1 15, P=2).

r"- 00 Updating of the edge again occurs with the value being added to the edge pool 412 as (Ni shown. At this time, it is seen that the edge pool 412 is now full and from which the edge with the smallest X-value is selected and emitted to the output list 404', and the corresponding limited pointer moved accordingly.

As seen in Fig. 12H, the next lowest edge crossing is that from the register 428 which is output (X=160 The edge pool 412 is again updated and the next small Xvalue emitted to the output list 404'.

At the end of scanline 35, and as seen in Fig. 121, the contents of the edge pool 412 are flushed to the output list 404' in order of smallest X-value. As seen in Fig. 12J, the next main edge list 404' and the main edge list 404 are swapped by exchanging their pointers in anticipation of rendering the next scanline 36. After the swapping, it is seen from Fig. 12J that the contents of the main edge list 404 include all edges current on scanline 36 arranged in order of X-position thereby permitting their convenient access which facilitates fast rendering.

Ordinarily, new edges are received by the edge processing module 400 in order of increasing X-position. When a new edge arrives, its position is updated (calculated for the next scanline to be rendered) and this determines further action as follows: if the updated position is less than the last X-position output on the line 498, the new edge is insertion sorted into the main spill list 406 and the corresponding limit register updated; 702810.doc -34o otherwise, if there is space, it is retained in the edge pool 412.

(Ni o As is apparent from the foregoing, the edge pool 412 aids in the updating of the Slists in an ordered manner in anticipation of rendering the next scanline in the rasterised image. Further, the size of the edge pool 412 may be varied to accommodate larger 5 numbers of non-ordered edges. However, it will be appreciated that in practice the edge 00 0 pool 412 will have a practical limit, generally dependent upon processing speed and (Ni N available memory with the graphic processing system. In a limiting sense, the edge Spool 412 may be omitted which would ordinarily require the updated edges to be insertion sorted into the next output edge list 404'. However, this situation can be avoided as a normal occurrence through the use of the spill lists mentioned above. The provision of the spill lists allows the described arrangement to be implemented with an edge pool of practical size and yet handle relatively complex edge intersections without having to resort to software intensive sorting procedures. In those small number of cases where the edge pool and spill list are together insufficient to accommodate the edge intersection complexity, sorting methods may be used.

An example of where the spill list procedure is utilised is seen in Fig. 14A where three arbitrary edges 60, 61 and 63 intersect an arbitrary edge 62 at a relative position between scanlines A and B. Further, the actual displayed pixel locations 64 for each of scanlines A, B, are shown which span pixel locations C to J. In the above described example where the edge pool 412 is sized to retain three edge records; it will be apparent that such an arrangement alone will not be sufficient to accommodate three edge intersections occurring between adjacent scanlines as illustrated in Fig. 14A.

Fig. 14B shows the state of the edge records after rendering the edges 60, 61 and 63 on scanline. The edge crossing H is that most recently emitted and the edge pool 412 is full with the updated X-values E, G and I for the edges 60, 61 and 63 respectively for 702810.doc O the next scanline, scanline B. The edge 62 is loaded into the current active edge record O 430 and because the edge pool 412 is full, the lowest X-value, corresponding to the edge is output to the output edge list 404'.

In Fig. 14C, the next edge crossing is emitted (X J for edge 62) and the corresponding updated value determined, in this case X C for scanline B. Because the 00 r new updated value X C is less than the most recent value X E copied to the output M"i N list 404', the current edge record and its corresponding new updated value is transferred Sdirectly to the output spill list 406'.

Fig. 14D shows the state of the edge records at the start of scanline B where it is seen that the main and output lists, and their corresponding spill components, have been swapped. To determine the first emitted edge, the edge 60 is loaded into the current active edge register 430 and the edge 62 is loaded into the spill active edge register 432.

The X-values are compared and the edge 62 with the least X-value (X C) is emitted, updated and loaded to the edge pool 412.

Edge emission and updating continues for the remaining edges in the main edge list 404 and at the end of the scanline, the edge pool 412 is flushed to reveal the situation shown in Fig. 14E, where it is seen that each of the edges 60 to 63 are appropriately ordered for rendering on the next scanline, having been correctly emitted and rendered on scanline B.

As will be apparent from the foregoing, the spill lists provide for maintaining edge rasterisation order in the presence of complex edge crossing situations. Further, by virtue of the lists being dynamically variable in size, large changes in edge intersection numbers and complexity may be handled without the need to resort to sorting procedures in all but exceptionally complex edge intersections.

702810.doc -36- O Preferably, the edge pool 412 is sized to retain eight edge records and the lists O 404, 404' together with their associated spill lists 406, 406' have a base (minimum) size Aof 512 bytes which is dynamically variable thereby providing sufficient scope for handling large images with complex edge crossing requirements.

rn 5 3.3 PRIORITY DETERMINATION MODULE r"- 00 The operation of the priority determination module 500 will now be described (Ni Swith reference to Fig. 5. The primary function of the priority determination module 500 Sis to determine those objects that make a contribution to a pixel currently being scanned, order those contributing objects in accordance with their priority levels, and generate colour composite messages for instructing the pixel compositing module 700 to composite the ordered objects to generate the required colour and opacity for the current pixel.

The priority determination module 500 receives incoming messages 498 from the edge processing module 400. These incoming messages may include load priority data messages, load fill data messages, edge crossing messages, and end of scanline messages. These messages first pass through a first-in first-out (FIFO) buffer 518 before being read by a priority update module 506. The FIFO 518 acts to de-couple the operation of the edge processing module 400 and the priority determination module 500.

Preferably the FIFO 518 is sized to enable the receipt from the edge processing module 400 and transfer of a full scanline of edge-crossings in a single action. Such permits the priority determination module 500 to correctly handle multiple edge-crossings at the same pixel location.

The priority determination module 500 is also adapted to access a priority state table 502, and a priority data table 504. These tables are used to hold information about each priority. Preferably, the priority state and priority data tables 502, 504 are combined 702810.doc -37- O in memory as a single level activation table 530, as shown in Fig. 18. Alternatively these O tables 502, 504 can be kept separate.

SPreferably, the priority properties and status table 34 includes at least the following fields as shown in Fig. 18 for each priority level: M 5 a fill-rule flag (FILLRULE_IS_ODD_EVEN) which indicates whether 00 this priority is to have its inside versus outside state determined by the application of the C€3 odd-even fill rule or the non-zero winding fill rule; O (ii) a fill counter (FILL COUNT) for storing a current fill count which is modified in a manner indicated by the fill rule each time an edge affecting this priority is crossed; (iii) a clipper flag CLIPPER) which indicates whether this priority is to be used for clipping or filling; (iv) a clip type flag (CLIP_OUT) which, for edges which have the clipper flag set, records whether the clipping type is a "clip-in" or a "clip-out"; a clip counter (CLIP COUNT) for storing a current clip count which is decremented and incremented when a clip-in type clip region affecting this priority is entered and exited respectively, and incremented and decremented when a clip-out type clip region affecting this priority is entered and exited respectively; and (vi) a flag (NEEDBELOW) which records whether this priority requires levels beneath it to be calculated first, referred to as the "need-below" flag.

(vii) a fill table address (FILL INDEX), which points to an address where the fill of the priority is stored; (viii) a fill type (FILL TYPE), (ix) a raster operation code (COLOUR_OP), 702810.doc -38an alpha channel operation code (ALPHA_OP) consisting of three flags S(LAO USE_D_OUT_S, LAO_USE S OUTD and LAO USE_S_ROP_D), S(xi) a stack operation code (STACK_OP), and (xii) a flag (X_INDEPENDENT) which records whether the colour of this M 5 priority is constant for a given Y, referred to here as the "x-independent" flag; and r- 00 (xiii) other information (ATTRIBUTES) of the priority.

Clipping objects are known in the art and act not to display a particular new

O

O object, but rather to modify the shape of another object in the image. Clipping objects can also be turned-on and turned-off to achieve a variety of visual effects. For example, the object 80 of Fig. 8A could be configured as a clipping object acting upon the object to remove that portion of the object 90 that lies beneath the clipping object 80. This may have the effect of revealing any object or image beneath the object 90 and within the clipping boundaries that would otherwise be obscured by the opacity of the object The CLIPPER flag is used to identify whether the priority is a clipping object. Also, the CLIP-OUT flag is used to determine whether the priority is a clip-in or a clip-out, and the CLIP COUNT is used in a similar fashion to FILL COUNT to determine whether the current pixel is within the clip region.

Figs. 13A and 13B demonstrate the application of the odd-even and non-zero winding rules, for activating objects. The relevant rule to be used is determined by means of the fill-rule flag FILL_RULEIS_ODD_EVEN.

For the purposes of the non-zero winding rule, Fig. 13A illustrates how the edges 71 and 72 of an object 70 are allocated a notional direction, according to whether the edges are downwards-heading or upwards-heading respectively. In order to form a closed boundary, edges link nose-to-tail around the boundary. The direction given to an edge for the purposes of the fill-rule (applied and described later) is independent of the order in 702810.doc -39- O which the segments are defined. Edge segments are defined in the order in which they are O tracked, corresponding to the rendering direction.

AFig. 13B shows a single object (a pentagram) having two downwards-heading edges 73 and 76, and three upwards-heading edges 74, 75 and 77. The odd-even rule operates by simply toggling a Boolean value in the FILL COUNT as each edge is crossed 00 by the scanline in question, thus effectively turning-on (activating) or turning-off (de- (Ni activating) an object's colour. The non-zero winding rule increments and decrements a Svalue stored in the fill counter FILL COUNT dependent upon the direction of an edge being crossed. In Fig. 13B, the first two edges 73 and 76 encountered at the scanline are downwards-heading and thus traversal of those edge increments the fill counter, to +1 and +2 respectively. The next two edges 74 and 77 encountered by the scanline are upwardsheading and accordingly decrement the fill counter FILL COUNT, to +1 and 0 respectively. The non-zero winding rule operates by turning-on (activating) an object's colour when the fill counter FILL COUNT is non-zero, and turning-off (de-activating) the object's colour when the fill counter FILL COUNT is zero.

The NEEDBELOW flag for a priority is established by the driver software and is used to inform the pixel generating system that any active priorities beneath the priority in question do not contribute to the pixel value being rendered, unless the flag is set. The flag is cleared where appropriate to prevent extra compositing operations that would otherwise contribute nothing to the final pixel value.

The raster operation code (COLOUR_OP), alpha channel operation (ALPHAOP) and stack operation (STACK_OP) together form the pixel operation (PIXEL_OP) that is to be performed by the pixel compositing module 700 on each pixel where the priority is active and exposed.

702810.doc 0 Preferably, most of the information contained in the combined table 34 is O directly loaded by instructions from the driver software. In particular, the fill-rule flag, Sthe clipper flag, the clip type flag, and the need-below flag, fill table address, fill type, raster operation, code, alpha channel operation code, stack operation code, x_independent M 5 flag, and other attributes may be handled in this manner. On the other hand, the fill r- 00 counter, and clip counter are initially zero and are changed by the priority determination (Ni N module 500 in response to edge crossing messages.

SThe priority determination module 500 determines that a priority is active at a pixel if the pixel is inside the boundary edges which apply to the priority, according to the fill-rule for that priority, and the clip count for the priority. A priority is exposed if it is the uppermost active priority, or if all the active priorities above it have their corresponding need-below flags set. In this fashion, pixel values may be generated using only the fill data of the exposed priorities. It is important to note that an object's priority designates the level location of the object in the z-order of the objects from the rearmost object to the foremost object. Preferably, a number of non-overlapping objects that have the same fill and compositing operation, and that form a contiguous sequence, may be designated as having the same priority. This effectively saves memory space in the fill table. Furthermore, the corresponding edge records of objects need only reference the corresponding priority in order to reference the corresponding fill and compositing operation.

Returning now to Fig. 5, the priority update module 506 maintains a counter 524 which records the scanline intersection coordinate up to which it has completed processing. This will be referred to as the current X of the priority update module 506.

The initial value at the start of a scanline is zero.

702810.doc -41- O Upon examining an edge crossing message received at the head of the FIFO 518, O the priority update module 506 compares the X intersection value in the edge crossing Smessage with its current X. If the X intersection value in the edge crossing message is less than or equal to the current X, the priority update module 506 processes the edge Mc, 5 crossing message. Edge crossing message processing comes in two forms. "Normal edge r"- 00 r processing" (described below) is used when the record in the priority state table 502 indicated by the priority in the edge crossing message has a clipper flag which indicates that this is not a clip priority. Otherwise, "clip edge processing" (described below) is performed.

"Normal edge processing" includes, for each priority in the edge crossing message and with reference to fields of the record of combined table 34 indicated by that priority, the steps of: noting the current fill count of the current priority; (ii) either: if the fill rule of the current priority is odd-even, setting the fill count to zero if it is currently non-zero, else setting it to any non-zero value, or if the fill rule of the current priority is non-zero winding, incrementing or decrementing (depending on the edge direction flag) the fill count; and (iii) comparing the new fill count with the noted fill count and if one is zero and the other is non-zero performing an "active flag update" (described below) operation on the current priority.

Some arrangements may use a separate edge crossing message for each priority rather than placing a plurality of priorities in each edge crossing message.

An active flag update operation includes first establishing a new active flag for the current priority. The active flag is non-zero if the fill count for the priority in the 702810 .doc -42- O priority state table 502 is non-zero and the clip count for the priority is zero, else the o active flag is zero. The second step in the active flag update operation is to store the Sdetermined active flag in an active flags array 508 at the position indicated by the current priority, then if the need-below flag in the priority state table for the current priority is C 5 zero, also storing the active flag in an opaque active flags array 510 at the position 00 indicated by the current priority.

(Ni S"Clip edge processing" includes, with reference to fields of the priority state Stable record indicated by the first priority in the edge crossing message, the steps of: noting the current fill count of the current priority; (ii) either: if the fill rule of the current priority is odd-even, setting the fill count to zero if it is currently non-zero else setting it to any non-zero value, or if the fill rule of the current priority is non-zero winding, incrementing or decrementing (depending on the edge direction flag) the fill count; and (iii) comparing the new fill count with the noted fill count and determining a clip delta value of: zero, if both the new fill count is zero and the noted fill count is zero, or both the new fill count is non-zero and the noted fill count is non-zero, plus one, if the clip type flag of the current priority is clip-out and the noted fill count is zero and the new fill count is non-zero, or the clip type flag of the current priority is clip-in and the noted fill count is non-zero and the new fill count is zero, or otherwise, minus one; and (iv) for every subsequent priority after the first in the edge crossing message, add the determined clip delta value to the clip count in the record in the priority 70281 O.doc 43 O state stable indicated by that subsequent priority, and if the clip count either moved from o non-zero to zero, or from zero to non-zero in that process, performing an active flag Supdate operation as described above on that subsequent priority. It should be noted that the initial value of each clip count is set by the LOAD_PRIORITY_PROPERTIES M 5 instruction described previously. The clip count is typically initialised to the number of r"- 00 clip-in priorities, which affect each priority.

(Ni Some arrangements do not associate a priority with a clip, but instead directly Sincrement and decrement the clip count of all priorities given in the edge crossing .message. This technique can be used, for example, when clip shapes are simple and do not require the application of a complex fill rule. In this specific application, the clip count of the level controlled by an edge is incremented for an upwards heading edge or decremented for a downwards heading edge. A simple closed curve, described anticlockwise, acts as a clip-in, whereas a simple closed curve, described clockwise, acts as a clip-out.

When the X intersection value in the edge crossing message is greater than the current X of the priority update module 506, the priority update module 506 forms a count of how many pixels to generate, being the difference between the X intersection value in the edge crossing message and the current X. This count is formatted into a priority generation message, which is sent via a connection 520 to a priority generation module 516. The priority update module 506 then waits for a signal 522 from the priority generation module 516 indicating that processing for the given number of pixels has completed. Upon receipt of the signal 522, the priority update module 506 sets its current X to the X intersection value in the edge crossing message and continues processing as described above.

70281 O.doc -44- O Upon receipt of a priority generation message 520, the priority generation o module 516 performs a "pixel priority generation operation" (described below) a number Sof times indicated by the count it has been supplied, thereupon it signals 522 the priority update module 506 that it has completed the operation.

M 5 Each pixel priority generation operation includes firstly using a priority encoder r"- 00 r- 514 (eg. a 4096 to 12 bit priority encoder) on the opaque active flags array 510 to MNi N determine the priority number of the highest opaque active flag. This priority (if any) is Sused to index the priority data table 504 and the contents of the record so referenced is formed into a fill priority message output 598 from the priority generation module 516 and sent to the fill colour determination module 600. Further, if a priority was determined by the previous step (ie. there was at least one opaque active flag set), the determined priority is held, and is referred to as the "current priority". If no priority was determined the current priority is set to zero. The priority generation module 516 then repeatedly uses a modified priority encoder 512 on the active flag array 508 to determine the lowest active flag which is greater than the current priority. The priority so determined (if any) is used to index the level activation table 530 and the contents of the record so'referenced is formed into a fill priority message. This fill priority message is then sent via the output 598 to the fill colour determination module 600, then the determined priority is used to update the current priority. This step is used repeatedly until there is no priority determined (that is, there is no priority flagged in the active flags, which is greater than the current priority). Then the priority generation module 516 forms an end of pixel message and sends it to the fill colour determination module 600. The priority determination module 500 then proceeds to the next pixel to generate another series of fill priority messages in similar fashion.

702810.doc O Turning now to Fig. 22A, there is shown an example of such a series of fill U priority messages 2200 generated by the priority determination module 500 for a single current pixel. As described above, these fill priority messages 2202 are first preceded by a START OF PIXEL command 2201. The fill priority messages 2202 are then sent in 5 priority order commencing with the lowest exposed active priority level. When there are 00 no more fill priority messages 2202 for the current pixel, the priority determination cl N module 500 then sends an ENDOFPIXEL message 2206.

SEach of one these fill priority messages 2202 preferably includes at least the following fields: An identifier code FILL_PRTY 2204 for identifying the message as a fill priority message. This code also includes an index LEVEL_INDX to the corresponding record in the level activation table 530, and also a code FIRSTPIXEL indicating whether or not this fill priority message belongs to a first pixel in a run of pixels having the same fill priority messages. The priority determination module 500 asserts the FIRST_PIXEL code for all those fill priority messages of a currently scanned pixel that is intersected by an edge as indicated by the edge crossing messages. The FIRST_PIXEL code is deasserted for all fill priority messages of a currently scanned pixel if there is no edges intersecting that pixel as indicated by the edge crossing messages.

(ii) A fill table address FILL_INDEX, (iii) A fill type FILL_TYPE, (iv) A raster operation code COLOR_OP, An alpha channel operation code ALPHA_OP, (vi) A stack operation code STACK_OP, and 702810.doc -46- (vii) A flag X IND which records whether the colour of this priority is o constant for a given Y, referred to here as the "x-independent" flag. This flag is asserted Swhen the colour for this priority is constant.

The values of fields (ii) to (vii) for the fill priority message are retrieved from the M€3 5 corresponding record in the combined table 34.

00 Preferably, the priority generation module 516 notes the value of the x- (Ni Sindependent flag of each fill priority message that it forwards to the fill colour Sdetermination module 600 while it processes the first pixel of a sequence. If all the (,i forwarded messages have the x-independent flag specified, all subsequent messages in the span of pixels between adjacent edge intersections can be replaced by a single repeat specification of count minus one. This is done by producing a repeat message and sending it to the fill colour determination module 600 in place of all further processing in this sequence. It will be appreciated that if all the fill priority messages of a first pixel in a span of pixels between adjacent edges have their x-independent flag asserted, then the colour and opacity of the pixels in the span of pixels will be constant. Thus in these cases, the pixel compositing module 700 need only composite the first pixel in the span of pixels to generate the required constant colour and opacity and pass this onto the pixel output module 800. The generated repeat command is then passed to the pixel output module 800 which reproduces the constant colour and opacity for the subsequent pixels in the span of pixels from the colour and opacity of the first pixel. In this fashion, the number of compositing operations performed by the pixel compositing module 700 is reduced.

As another preferred feature to the basic operation described above, the priority generation module 516 sends the highest opaque priority via the connection 522 to the priority update module 506 after each edge crossing message. The priority update 702810.doc -47- Smodule 506 holds this in a store 526. The priority determination module 506 then, o instead of a simple test that the X intersection in the message is greater than the current X, performs a test that the X intersection in the message is greater than the current X and that at least one of the levels in the message is greater than or equal to the highest opaque M 5 priority, before producing a fill priority message. By doing this, fewer pixel priority r- 00 determination operations may be done and longer repeat sequences may be generated.

Using the example of the graphic objects shown in Figs. 8A, 9A and 9B, the Spriority update process described above can be illustrated, for scanline 35 using the edge crossings seen from Figs. 12C to 12J, as seen in Figs. 15A to Figs. 15A to 15E illustrate operation of the priority tables 502 and 504 which, in a preferred implementation are merged into a single table (see Fig. 18), referred to as the level activation table (LAT) 530 and which is depicted together with arrays 508, 510 and encoders 512 and 514.

As seen in Fig. 15A, edge crossing messages are received in order for a scanline from the edge processing module 400 and are loaded into the table 530, which is arranged in priority order. The edge crossing messages include, in this example, an incrementing direction according to the non-zero winding rule of the edge traversal. It is possible for no entries in the level activation table 530 to be set.

The level activation table 530 includes column entries for fill count, which are determined from the edge according to the non-zero winding rule or, where appropriate, the odd-even rule. The need-below flag is a property of a priority and is set as part of the LOAD PRIORITIES PROPERTIES instruction. The need-below is set for all priority levels when the table 530 is loaded. Other columns such as "clip count" and "fill index table" may be used, but for this example are omitted for simplicity of explanation. Where no level is active the corresponding entries are set to zero. Further, the values of the 702810 .doc -48- O arrays 510 and 508 are updated from the table 530 after receiving a subsequent edge O crossing.

From Fig. 15A, it will be apparent that, for convenience, a number of records have been omitted for clarity. As described previously, the contents of the table 530, M€3 5 where not used in the priority determination module 500, are passed as messages to each r- 00 of the fill colour determination module 600 for pixel generation, and to the pixel (Ni N compositing module 700 for compositing operations.

The first edge crossing for scanline 35 (Fig. 12E) is seen in Fig. 15A where for P= 1, the fill count is updated to the value of the edge according to the non-zero winding rule. The "need-below" flag for this level has been set to zero by the driver software as the object in question is opaque.

Because a previous state of the table 530 was not set, the arrays 510 and 508 remain not set and the priority encoder 514 is disabled from outputting a priority. This is interpreted by priority generation module 516 which outputs a count n=40 (pixels) for a "no object" priority (eg: P being the first, blank, portion of the scanline Fig. 15B shows the arrangement when the edge crossing of Fig. 12F is received.

The fill count is updated. The arrays 510 and 508 are then set with the previous highest level from the table 530. At this time, the module 516 outputs a count n=45, P=I representing the edge 96 of the opaque red object 90 before intersection with the semitransparent triangle Fig. 15C shows the arrangement when the edge crossing of Fig. 12G is received.

Note that the fill count has been adjusted downwardly because of the non-zero winding rule. Because the object that is valid prior to receiving the current edge crossing is not opaque, the modified priority encoder 512 is used to select the priority P=2 as the highest active level which is output as is current for n=(l 15-85)=30 pixels.

702810.doc -49- O Fig. 15D shows the arrangement when the edge crossing of Fig. 12H is o received. Note that previously changed "need-below" for P=2 has been transferred to the Sactive array 508, thus permitting the priority encoder to output a value P=l current for n=(160-115)=45 pixels.

M 5 Fig. 15E shows the result when the edge crossing of Fig. 121 is received, r- 00 providing for an output of P=0 for n=(180-160)=20 pixels.

As such, the priority module 500 outputs counts of pixels and corresponding priority display values for all pixels of a scanline.

3.4 FILL COLOUR DETERMINATION MODULE The next module in the pipeline is the fill colour determination module 600, the operation of which will now be described with reference to Fig. 6. Incoming messages 598 from the priority determination module 500, which include set fill data messages, repeat messages, fill priority messages, end of pixel messages, and end of scanline messages, first pass to a fill lookup and control module 604. The fill lookup and control module 604 maintains a current X position counter 614 and a current Y position counter 616 for use by various components of the fill colour determination module 600.

Upon receipt of an end of scanline message, the fill lookup and control module 604 resets the current X counter 614 to zero and increments the current Y counter 616. The end of scanline message is then passed to the pixel compositing module 700.

Upon receipt of a set fill data message, the fill lookup and control module 604 stores the data in the specified location 602 of the fill data table 36.

Upon receipt of a repeat message, the fill lookup and control module 604 increments the current X counter 614 by the count from the repeat message. The repeat message is then passed to the pixel compositing module 700.

702810.doc O Upon receipt of an end of pixel message 2202, the fill lookup and control o module 604 again increments the current X counter 614, and the end of pixel message is Sthen passed to the pixel compositing module 700.

Upon receipt of a fill priority message, the fill lookup and control module 604 Mc, 5 performs operations which include: 00 the fill type from the fill priority message is used to select a record size C€3 N in the fill data table 36; (ii) the fill table address from the fill priority message, and the record size as determined above, is used to select a record from the fill data table 36; (iii) the fill type from the fill priority message is used to determine and select a sub-module to perform generation of the fill colour. The sub-modules may include a raster image module 606, a flat colour module 608, a linearly ramped colour module 610, and an opacity tile module 612; (iv) the determined record is supplied to the selected sub-module 606-612; the selected sub-module 606-612 uses the supplied data to determine a colour and opacity value; (vi) the determined colour and opacity is combined with remaining information from the fill colour message, namely the raster operation code, the alpha channel operation code, the stack operation code, to form a colour composite message 2208, which is sent to the pixel compositing module 700 via the connection 698.

Thus, a message sequence 2200 of Fig. 22A starting with a start of pixel message 2201 message, then fill priority messages 2202 followed by an end of pixel message 2206 is transformed into a message sequence 2212 of Fig. 22B comprising a start of pixel message 2201, colour composite messages 2208 followed by an end of pixel 702810.doc -51 O message 2206. These colour composite messages 2202 preferably includes the same o fields as the fill priority messages 2202, with the following exceptions: code CLR_CMP 2210 for identifying the message as a colour composite message. This CLR_CMP code also includes the index to the corresponding record in the level activation table 530; o (ii) a colour and opacity field for containing the colour and opacity value of N the priority. The latter replaces the fill index and fill type fields of the fill priority messages.

In the preferred arrangement, the determined colour and opacity is a red, green, blue and opacity quadruple with 8-bit precision in the usual manner giving 32 bits per pixel. However, a cyan, magenta, yellow and black quadruple with an implied opacity, or one of many other known colour representations may alternatively be used. The red, green, blue and opacity case is used in the description below, but the description may also be applied to other cases.

The operation of the raster image module 606, the flat colour module 608, the linearly ramped colour module 610, and the opacity tile module 612 will now be described.

The flat colour module 608 interprets the supplied record as a fixed format record containing three 8-bit colour components (typically interpreted as red, green and blue components) and an 8-bit opacity value (typically interpreted as a measure of the fraction of a pixel which is covered by the specified colour, where 0 means no coverage, that is complete transparency, and 255 means complete coverage, that is, completely opaque). This colour and opacity value is output directly via the connection 698 and forms the determined colour and opacity without further processing.

702810 .doc -52- SThe linearly ramped colour module 610 interprets the supplied record as a fixed o format record containing four sets of three constants, cx, cy, and d, being associated with 0) Sthe three colour and one opacity components. For each of these four sets, a result value r is computed by combining the three constants with the current X count, x, and the current Y count, y, using the formula: 00 r clamp( cx x cy y d)

C",

Where the function "clamp" is defined as: 255 255 x clamp(x) Lx 0 x 255 0 x<0 The four results so produced are formed into a colour and opacity value. This colour and opacity value is output directly via the connection 698 and forms the determined colour and opacity without further processing.

The opacity tile module 612 interprets the supplied record as a fixed format record containing three 8-bit colour components, an 8-bit opacity value, an integer X phase, a Y phase, an X scale, a Y scale, and a 64 bit mask. These values originate in the display list generation and contained typically in the original page description. A bit address, a, in the bit mask, is determined by the formula: a x/2Sx px mod 8 y/2sY py) mod 8 x 8 The bit at the address in the bit mask is examined. If the examined bit is one, the colour and opacity from the record is copied directly to the output of the module 612 and forms the determined colour and opacity. If the examined bit is zero, a colour having 702810.doc -53- O three zero component values and a zero opacity value is formed and output as the o determined colour and opacity.

SThe raster image module 606 interprets the supplied record as a fixed format record containing six constants, a, b, c, d, tx, and ty; an integer count of the number of M 5 bits (bpl) in each raster line of the raster image pixel data 16 to be sampled; and a pixel r"- 00 r- type. The pixel type indicates whether the pixel data 16 in the raster image pixel data is to be interpreted as one of: one bit per pixel black and white opaque pixels; (ii) one bit per pixel opaque black or transparent pixels; (iii) 8 bits per pixel grey scale opaque pixels; (iv) 8 bits per pixel black opacity scale pixels; 24 bits per pixel opaque three colour component pixels;, or (vi) 32 bits per pixel three colour component plus opacity pixels.

Many other formats are possible.

The raster image module 606 uses the pixel type indicator to determine a pixel size (bpp) in bits. Then a bit address, a, in the raster image pixel data 16 is calculated having the formula: a=bpp* L a* x c y tx J bpl* L b x d y ty] A pixel interpreted according to the pixel type from the record 602 is fetched from the calculated address in the raster image pixel data 16. The pixel is expanded as necessary to have three eight bit colour components and an eight bit opacity component. By "expanded", it is meant for example, that a pixel from an eight bit per pixel grey scale opaque raster image would have the sampled eight bit value applied to 702810.doc -54- 2 each of the red, green and blue component, and the opacity component set to fully o opaque. This then forms the determined colour and opacity output 698 to the pixel Scompositing module 700.

As a consequence, the raster pixel data valid within a displayable object is C 5 obtained through the determination of a mapping to the pixel image data within the

OO

00 Smemory 16. This effectively implements an affine transform of the raster pixel data into N the object-based image and is more efficient than prior art methods which transfer pixel Sdata from an image source to a frame store where compositing with graphic objects may occur.

As a preferred feature to the above, interpolation between pixels in the raster image pixel data 16 may optionally be performed by first calculating intermediate results p, and q according to the formulae: p=a*x c*y tx q=b*x d*y ty Next the bit addresses, aOO, a01, al0, and all, of four pixels in the raster image pixel data 16 are determined according to the formulae: aOO bpp Lp] bpl LqJ a01 a00 bpp al0 a00 bpl all aOO bpl bpp 702810.doc O Next, a result pixel component value, r, is determined for each colour and o opacity component according to the formula: r interp(interp(get(a00), get(a01), interp(get(al0),get(al q) c 00 where the function "interp" is defined as: Sinterp(a, b, c) a (c-LcJ) In the above equations, the representation LvalueJ floor (value), where a floor operation involves discarding the fractional part of the value.

The get function returns the value of the current pixel component sampled from the raster image pixel data 16 at the given bit address. Note that for some components of some image types this can be an implied value.

As a preferred feature to the above, image tiling may optionally be performed by using x and y values in the above equations which are derived from the current X and Y counters 614,616 by a modulus operation with a tile size read from the supplied record.

Many more such fill colour generation sub-modules are possible.

PIXEL COMPOSITING MODULE The operation of the pixel compositing module 700 will now be described. The primary function of the pixel compositing module is to composite the colour and opacity of all those exposed object priorities that make an active contribution to the pixel currently being scanned.

Preferably, the pixel compositing module 700 implements a modified form of the compositing approach as described in "Compositing Digital Images", Porter, T: Duff, T; 702810.doc -56- O Computer Graphics, Vol 18 No 3 (1984) pp 2 5 3 2 5 9 ("Porter And Duff'). Examples of O Porter and Duff compositing operations are shown in Fig. 21. However, such an Sapproach is deficient in that it only permits handling a source and destination colour in the intersection region formed by the composite, and as a consequence is unable to M€3 5 accommodate the influence of transparency outside the intersecting region. One method 00 of overcoming this problem is to pad the objects with completely transparent pixels. Thus cN the entire area becomes in effect the intersecting region, and reliable Porter and Duff compositing operations can be performed. This padding is achieved at the driver software (,i level where additional transparent object priorities are added to the combined table.

These Porter and Duff compositing operations are implemented utilising appropriate colour operations as will be described below in more detail with reference to Figs. and 19.

Preferably, the images to be composited are based on expression trees.

Expression trees are often used to describe the compositing operations required to form an image, and typically comprise a plurality of nodes including leaf nodes, unary nodes and binary nodes. A leaf node is the outermost node of an expression tree, has no descendent nodes and represents a primitive constituent of an image. Unary nodes represent an operation which modifies the pixel data coming out of the part of the tree below the unary operator. A binary node typically branches to left and right subtrees; wherein each subtree is itself an expression tree comprising at least one leaf node. An example of an expression tree is shown in Fig. 17C. The expression tree shown in Fig. 17C comprises four leaf nodes representing three objects A, B, and C, and the page. The expression tree of Fig. 17C also comprises binary nodes representing the Porter and Duff OVER operation. Thus the expression tree represents an image where the object A is composited 702810.doc -57- O OVER the object B, the result of which is then composited OVER object C, and the result 0 of which is then composited OVER the page.

A Turning now to Figs. 17A and 17B, there is shown a typical binary compositing

O

operation in an expression tree. This binary operator operates on a source object (src) and (C 5 a destination object (dest), where the source object src resides on the left branch and the 00 destination object (dest) resides on the right branch of the expression tree. The binary Soperation is typically a Porter and Duff compositing operation. The area src n dest 0 Srepresents the area on the page where the objects src and dest objects intersect (ie both active), the area srcndest where only the src object is active, and the area src n dest where only the dest object is active.

The compositing operations of the expression tree are implemented by means of the pixel compositing stack 38, wherein the structure of the expression tree is implemented by means of appropriate stack operations on the pixel compositing stack 38.

Turning now to Fig. 23, there is shown the pixel compositing module 700 in more detail. The pixel compositing module 700 receives incoming messages from the fill colour determination module 600. These incoming messages include repeat messages, series of colour composite messages (see Fig. 22B), end of pixel messages, and end of scanline messages, and are processed in sequence.

The pixel compositing module 700 includes a decoder 2302 for decoding these incoming messages, and a compositor 2304 for compositing the colours and opacities contained in the incoming colour composite messages. Also included is a stack controller 2306 for placing the resultant colours and opacities on a stack 38, and an output FIFO 702 for storing the resultant colour and opacity.

During the operation of the pixel compositing module 700, the decoder 2302, upon the receipt of a colour composite message, extracts the raster operation 702810.doc -58- SCOLOUROP and alpha channel operation codes ALPHA_OP and passes them to the U compositor 2304. The decoder 2302 also extracts the stack operation STACK_OP and colour and opacity values COLOUR, ALPHA of the colour composite message and passes them to the stack controller 2306. Typically, the pixel composing module 700 MC, 5 combines the colour and opacity from the colour composite message with a colour and r- 00 opacity popped from the pixel compositing stack 38 according to the raster operation and (Ni alpha channel operation from the colour composite message. It then pushes the result back onto the pixel compositing stack 38. More generally, the stack controller 2306 forms a source (src) and destination (dest) colour and opacity, according to the stack operation specified. If at this time, or during any pop operation from the pixel compositing stack, the pixel compositing stack 38 is found to be empty, an opaque white colour value is used without any error indication. These source and destination colours and opacity are then made available to the compositor 2304 which then performs the compositing operation in accordance with the COLOUR_OP and ALPHA_OP codes.

The resultant (result) colour and opacity is then made available to the stack controller 2306, which stores the result on the stack 38 in accordance with the STACK_OP code.

These stack operations are described in more detail below.

During the operation of the pixel compositing module 700, if the decoder 2302 receives an end of pixel message, it then instructs the stack controller 2306 to pop a colour and opacity from the pixel compositing stack 38. If the stack 38 is empty an opaque white value is used. The resultant colour and opacity is then formed into a pixel output message which is forwarded to the pixel output FIFO 702. If the decoder 2302 receives a repeat message or an end of scanline message, the decoder 2302 by-passes (not shown) the compositor 2304 and stack controller 2306 and forwards the messages to the pixel output FIFO 702 without further processing.

702810 .doc -59- O Figs. 24A, B, C, and D show the operation performed on the pixel compositing o stack 38 for each of the various stack operation commands STACK_OP in the colour Scomposite messages.

Fig 24A shows the standard operation STD_OP 2350 on the pixel compositing c 5 stack 38, where the source colour and opacity (src) are obtained from the colour 00 r composite message, and the destination colour and opacity (dest) are popped from the top of the pixel compositing stack 38. The source colour and opacity (src) is taken from the O value in a current colour composite message for the current operation, and destination colour and opacity (dest) is popped from the top of the stack 38. The result of the COLOUROP operation performed by the compositor 2304 is pushed back onto the stack 38.

Fig 24B shows the NO_POP_DEST stack operation 2370 on the pixel compositing stack 38. The source colour and opacity (src) is taken from the value in a current composite message for the current operation, and the destination colour and opacity (dest) is read from the top of the stack 38. The result of the COLOUR_OP operation performed by the compositor 2304 is pushed onto the top of the stack 38.

Fig 24C shows the POP_SRC stack operation, where the source colour and opacity are popped from the top of the stack, and the destination colour and opacity is popped from the next level down the stack. The result of the COLOUR_OP operation performed by the compositor 2304 is pushed onto the top of the stack.

Fig. 24D shows the KEEP_SRC stack operation, where the source colour and opacity are popped from the top of the stack, and the destination colour and opacity is popped from the next level down the stack. The result of the COLOUR_OP operation performed by the compositor 2304 is pushed onto the top of the stack.

Other stack operations can be used.

702810.doc O The manner in which the compositor 2304 combines the source (src) colour and O opacity with the destination (dest) colour and opacity will now be described with Sreference to Figs. 7A to 7C. For the purposes of this description, colour and opacity values are considered to range from 0 to 1, (ie: normalised) although they are typically M 5 stored as 8-bit values in the range 0 to 255. For the purposes of compositing together two r'- 00 r- pixels, each pixel is regarded as being divided into two regions, one region being fully opaque and the other fully transparent, with the opacity value being an indication of the Sproportion of these two regions. Fig. 7A shows a source pixel 702 which has some three component colour value not shown in the Figure and an opacity value, The shaded region of the source pixel 702 represents the fully opaque portion 704 of the pixel 702.

Similarly, the non-shaded region in Fig. 7A represents that proportion 706 of the source pixel 702 considered to be fully transparent. Fig. 7B shows a destination pixel 710 with some opacity value, The shaded region of the destination pixel 710 represents the fully opaque portion 712 of the pixel 710. Similarly, the pixel 710 has a fully transparent portion 714. The opaque regions of the source pixel 702 and destination pixel 710 are, for the purposes of the combination, considered to be orthogonal to each other. The overlay 716 of these two pixels is shown in Fig. 7C. Three regions of interest exist, which include a source outside destination 718 which has an area of so (1 do), a source intersect destination 720 which has an area of so do, and a destination outside source 722 which has an area of (1 so) do. The colour value of each of these three regions is calculated conceptually independently. The source outside destination region 718 takes its colour directly from the source colour. The destination outside source region 722 takes its colour directly from the destination colour. The source intersect destination region 720 takes its colour from a combination of the source and destination colour.

702810.doc -61 0 The process of combining the source and destination colour, as distinct from the (Ni o other operations discussed above is termed a raster operation and is one of a set of Sfunctions as specified by the raster operation code from the pixel composite message.

Some of the raster operations included in the described arrangement are shown in Fig. 19.

5 Each function is applied to each pair of colour components of the source and destination 00 0 colours to obtain a like component in the resultant colour. Many other functions are (Ni N possible.

SThe alpha channel operation from the composite pixel message is also considered during the combination of the source and destination colour. The alpha channel operation is performed using three flags LAOUSED_OUTS, LAO_USESOUT_D, LAO_USESROP_D, which respectively identify the regions of interest (1 so do, so (1 do), and so do in the overlay 716 of the source pixel 702 and the destination pixel 710. For each of the regions, a region opacity value is formed which is zero if the corresponding flag in the alpha channel operation is not set, else it is the area of the region.

The resultant opacity is formed from the sum of the region opacities. Each component of the result colour is then formed by the sum of the products of each pair of region colour and region opacity, divided by the resultant opacity.

As shown in Figs. 20A and 20B, the Porter and Duff operations may be formed by suitable ALPHAOP flag combinations and raster operators COLOR_OP, provided that both operands can be guaranteed to be active together. Because of the way the table is read, if only one of the operands is not active, then the operator will either not be performed, or will be performed with the wrong operand. Thus objects that are to be combined using Porter and Duff operations may be padded out with transparent pixels to an area that covers both objects in the operation. Other transparency operations may be 702810.doc 62 0 formed in the same way as the Porter and Duff operations, using different binary O operators as the COLOR_OP operation.

SThe resultant colour and opacity is passed to the stack controller circuit and pushed onto the pixel compositing stack 38. However, if the stack operation is 5 STACK_KEEP_SRC, the source value is pushed onto the stack before the result of the 00 0 colour composite message is pushed.

(Ni N When an end of pixel message is encountered, the colour and opacity value on Stop of the stack is formed into a pixel output message, and sent to the pixel output module (,i 800. Repeat pixel messages are passed through the pixel compositing module 700 to the pixel output module 800.

3.6 PIXEL OUTPUT MODULE The operation of the pixel output module 800 will now be described. Incoming messages are read from the pixel output FIFO, which include pixel output messages, repeat messages, and end of scanline messages are processed in sequence.

Upon receipt of a pixel output message the pixel output module 800 stores the pixel and also forwards the pixel to its output. Upon receipt of a repeat message the last stored pixel is forwarded to the output 898 as many times as specified by the count from the repeat message. Upon receipt of an end of scanline message the pixel output module 800 passes the message to its output.

The output 898 may connect as required to any device that utilizes pixel image data. Such devices include output devices such as video display units or printers, or memory storage devices such as hard disk, semiconductor RAM including line, band or frame stores, or a computer network. However, as will be apparent from the foregoing, a method and apparatus are described that provide for the rendering of graphic objects with 702810.doc 63 o full functionality demanded by sophisticated graphic description languages without a Sneed for intermediate storage of pixel image data during the rendering process.

State Table Optimisation 5 Two difficulties arise when compositing objects described by an expression tree. If 00 0 a branch of the expression tree is right-biased, then a change of state in an operand near (Ni N the base of the branch needs to be propagated through each node above the changed Soperand. In the system described above, this difficulty results in a large amount of (,i processing in the priority determination module 500 when updating the level activation table 530. The second difficulty encountered is that the contribution of a node in the expression tree is determined by nodes further up the tree, requiring that the tree be traversed top-down, rather than bottom-up.

The present arrangement is intended to ameliorate one or more of these problems. The arrangement identifies those operations whose behaviour, with regard to contributing data up the expression tree when one branch of the operation is active, is independent of the activity of the other branch of the operation. The most useful case is to identify those operations which contribute data when the right branch is active, independent of the state of the left branch. Right-biased trees are more common in the realm of interest, and right-biased trees minimise stack depth in the compositing engine.

Operations that contribute data when their right branch is active will hereafter be referred to as 'right-friendly' operations. Similarly, operations that contribute data up the tree when the left branch is active, independent of the state of the right branch, are referred to as 'left-friendly'. If both conditions are true, then the operation is 'both-friendly'. The arrangement allows any right-biased branch of depth one operations to be optimized so 70281 O.doc 64 O that only operations that are not independent of the state of the right branch are processed o when maintaining the activation state of the table representing the expression tree.

SAs described more fully below, the level activation table 530 includes a counter on each level to count the number of objects active in the right branch of the expression tree 5 below the current level. Using this counter, an instruction stream 698 for the stack- 00 0machine-based compositing module 700 can be built from visible instructions in the level (Ni Sactivation table 530, working from bottom to top rather than top to bottom. This allows Sinstructions to be sent immediately upon being encountered rather than requiring buffering.

In the present system, the images being processed are described by expression trees.

The trees are formatted as a linear table for use in the pixel sequential renderer 20. Such formatting is initiated by the driver software operating on the host processor 2.

Instructions are passed to the pixel sequential renderer 20 to cause the linear table representing the expression tree to be stored in the level activation table 530 (see Fig. 18).

The priority determination module 500 uses the level activation table 530 in constructing the fill priority message output 598 that is forwarded to the fill colour determination module 600. Note that in Fig. 5 the level activation table 530 is shown as two modules, a priority state table 502 and a priority data table 504.

4.1 Right-friendly and left-friendly operations in expression trees Consider the graphical objects R and L in Fig. 25A. Object R is the result of the right branch of a compositing operation, and object L is the result of the left branch of the operation. The two objects divide the plane into four regions. In the three labelled regions (L R, L nR and L nR- either or both of objects R and L is active. The 702810.doc 65 O fourth region is the surrounding portion of the plane in which neither of the objects is active.

An operation that is left-friendly produces data in regions L n R and L r R. An operation that is right-friendly produces data in regions L r- R and L r) R. An operation 5 that is both-friendly produces data in regions L n R Lr R and L r R. An operation 00 that is left unfriendly does not produce data in L r R. An operation that is right unfriendly does not produce data in region L rm R.

C If graphical objects are partially transparent, they can be considered to partially cover each pixel in a region, allowing objects below them to show through the transparent part and confining any operation performed between the objects to that portion of the pixel that is covered by both objects. If the transparency of the two objects is independent, then the portions can be arranged orthogonally, as shown in Fig. 25B. The operations on the transparency are defined by which of these three pixel regions contribute to the pixel value. Thus the per-pixel transparency operation can be used to determine the behaviour of the operation applied to regions. In particular, the transparency operation may be used to determine whether an operation is left or right friendly.

Referring to Fig. 7C, and to Fig. 25, it may be seen that there is a correspondence between the regions of a pixel that are controlled by the flags making up the opacity operation and the regions of the page whose presence or absence determines the friendliness of an operation. In the case where the opacity of objects is unknown, or known to be non-unity when the driver software compiles the level activation table 530, the R r L region of Fig. 25A is always included. However, because of this correspondence, the opacity operation's LAOUSESOUTD flag determines whether region L r R produces data, and the LAOUSEDOUTS flag determines whether 702810.doc -66- Sregion L r- R produces data. If opacities of the objects are known to be unity, the driver o can use the LAOUSESROPD flag of the opacity operation to determine whether the R n L region contributes data.

For convenience, if an operation has data available in its left operand, it will be M 5 referred to as left-active, and if it has data available in its right operand it will be referred r"- 00 r to as right-active. When an object is directly activated by its edges, the operation to put (Ni the object on the page is left-active.

SFig. 26 shows an example of an expression tree 2600. The right-most branch of the

(I

expression tree 2600 is the spine of the tree 2600. The topmost operation in tree 2600 is operation 2601, and the lowest operation along the spine is operation 2605, which has a left leaf-node 2619 and a right leaf-node 2621. Operation 2603 on the spine has a left branch 2607 that consists of four operations X14, X13, X12 and XI 1, where X14 is the operation immediately below operation 2603 and X11 is the lowest operation in branch 2607. The sequence of operations in branch 2607 is right-biased. X14 has a left leaf node 2609, X13 has a left leaf node 2611, X12 has a left leaf node 2613 and X11 has two leaf nodes 2615, 2617. A base node is the lowest node in a branch (X11I in the case of branch 2607) and an ancestor node of a current node is the first node above the current node that is not left-friendly.

If the operations X1l-X13 are all both-friendly, then if any of these operations is activated, the operation X14 at the ancestor node of the branch 2607 is right-active.

Because the intervening operations between the active node and the ancestor node are left-friendly, they will contribute data when active, regardless of the state of lower right branch operands. Because the intervening operations are right-friendly, they do not modify the activity of the operations below them in the right branch. It therefore suffices to maintain a count in operator X14 of the number of right-branch operands that are 702810.doc -67- O active, and not to update the contribution states of the intervening operators. The count is o maintained by the priority determination module 500,as described below in more detail.

SNote that in the hardware implementation described below with reference to Figs. 33-35, the counters of intervening levels are updated by the circuitry. However, in a software M 5 implementation, there is no need to update the intervening levels.

r- 00 If, for example, operation X12 is activated, the count in level X14 (the ancestor (Ni node) is incremented. Because the intervening operation X13 is both-friendly, the count Sof X13 does not need to be incremented, since operation X12 does not affect the (,i activation of X13 (which is left-friendly) and operation X13 does not affect the activation of the right-hand operations X11I and X12 (because X13 is right-friendly).

Note, however, that the compositing operation required to be performed by an operator cannot be determined directly from the activity state of a node. That is to say, the replacement of the specified operation on a level with a PUSH in the case where the right branch of the level is inactive cannot be performed from data present on the level.

However, as described below in Section 4.4, this replacement with a PUSH can be performed in the command-generation stage, i.e. when the priority generation module 516 constructs the fill priority message 598 to send to the fill colour determination module 600.

If the operations Xll-X13 are all right-friendly, then if any of operations X11- X13 is activated, the operations between the activated level and the ancestor node X14 become right-active. If the intervening operations are not left-friendly, they contribute data depending on the activity of the right branch, but because they are right-friendly they do not affect the activity of the lower levels. In the case where the intervening operations are not left-friendly, the right-counters of the intervening levels must be incremented so that the activity of any left-unfriendly operations can be determined.

702810.doc -68- O Say, for example, that operation X13 is left-unfriendly and right-friendly. When Soperation X12 or X11 is activated, this will affect the activation of X13 because it is left Sunfriendly. Thus the right count of X13 needs to be incremented or decremented by the activation or de-activation of levels X11, X12. so that the activity of X13 can be M 5 determined. However, the right-friendly nature of the level X13 means that no masking 00 r- of right-branch levels Xll,X12 is required (masking of branches is described below).

N Decisions regarding masking are made at the critical level X14.

SAs before, doing this does not allow the determination of the compositing operation required to be performed by an operator directly from branch activity fields in the level activation table. Again, replacement of the first operation encountered with a PUSH can be performed in the command-generation stage.

If a right-biased branch of the expression tree contains operations that are not rightfriendly, then such operations must be treated as the ancestor node of their dependent subbranch. The count for the right hand branch is kept in the level of the ancestor node, and is used in determining whether the level contributes data up the expression tree. If the ancestor node is not contributing, then all of the levels on the sub-branch are masked by the node. The parameters for the masking are contained within the level activation table 530. All levels in the non-contributing branch are masked.

In the case of operations that are not left-friendly, it is most practical for a software implementation to treat these nodes as ancestor nodes, in the same way as for operations that are not right-friendly. However, in a hardware implementation, there is a counter in each level of the priority table 530 which can be used to determine the activity of dependent objects: a signal is generated to simultaneously increment/decrement every such counter up to the ancestor level when a level becomes active/inactive. This allows 702810.doc -69- O logic associated with a level to determine whether or not the level contributes, on the o basis of the activity of the dependent right branch.

SThis optimisation procedure may be expanded to include left-biased branches.

However, display lists for printing are usually optimised to minimise the stack depth required by the pixel compositing process, and so left branches tend to be short, reducing 00 the benefit to be obtained by optimising left-friendly operations. For the sake of (Ni N simplicity, a system that only uses right friendly operations will be considered here.

SHowever, it will be appreciated that analogous procedures may be applied if it is necessary or desirable to optimise left-friendly operations.

Note that stack pop operations are not considered friendly, because the activity of the right branch determines whether the pop operation needs to be performed.

4.2 Tabular expression of expression trees The pixel sequential renderer 20 uses a table that is loaded as a linearised representation of the expression tree. The table is structured such that the top of the right branch of an operation is stored as the level immediately below the base of the left branch of the operation. The top of the left branch of an operation is the level immediately below the operation. To identify the structure of the tree, each level of the table contains a field that identifies the base of the left branch and a field that identifies the base of the right branch.

Fig. 28 shows a single level 2800 of an entry in the level activation table 530.

Note that in the present embodiment of the renderer 20, the fields in the level 2800 replace the table values shown in Fig. 18.

Some of the fields in Fig. 28 are descriptive of the structure of the expression tree represented in the level activation table 530. The field L base IX 2810 indicates the 702810.doc O base node of the left branch of the level. The field R base IX 2811 contains the base of o the right branch. The field Ancestor IX 2812 is the index of the level of the ancestor node Aof the level represented in the entry 2800. The ancestor node is either the first node above the present node in the right branch that is not left-friendly, or the top node of the branch, M 5 if all operations in the right branch are left-friendly. Operations contained in subr"- 00 branches cannot be ancestor nodes of nodes in a different branch.

The levels 2800 of the level activity table 530 are entered into the table such that the top of the right branch of an operation is the level immediately below the base of the left branch. The top of the left branch of an operation is stored immediately below the operation. If the ancestor IX field 2812 is NULL, then no further levels are activated by the present level. In particular, entries on the right most branch of the expression tree representing the page (referred to as the spine) have a NULL ancestor index 2812.

Entries on the spine are those which actually put colour on the page. Because the page is the default background, entries on the spine may be considered to be always right-active.

If the L base IX field 2810 is set to NULL, it indicates that the present level 2800 is directly activated. Setting the R base IX field 2811 to NULL indicates that the operation at the level 2800 may be performed with the default background.

If the entry for the base of the left branch (field 2810) is NULL, then level 2800 includes an index Fill IX 2816 that provides an index into the fill table 36 for the colour of the left branch. In this case the left branch is directly activated by an edge. When the base of the left branch (L base IX2810) is not NULL, the colour for the left branch is the result of previous operations in the expression tree, and the colour for the left branch is taken from the top of the stack. In this case, the activity of the left branch is determined by the contribution of other levels.

702810.doc -71 O Note that the left leaf node of an operation is stored on the same level as the o operation. Where the operation has a right leaf node, an extra level with a PUSH Soperation is added to the expression tree and the table 530. This is illustrated in Figs. 27A and 27B. Fig. 27A shows an operation Y12 having a left leaf node Y1 and a right leaf node Y13. As seen in Fig. 27B, an additional node 2701 is added to the expression tree, 00 containing a PUSH operation. Thus, Y11 is still a left leaf node of operation Y12. Leaf (Ni node Y13 becomes a left leaf node of the PUSH operation 2701, which forms a right branch of operation Y12.

Each table level 2800 includes three flags 2807, 2808, 2809 that determine whether level 2800 contributes data to other operations further up the expression tree.

The three flags are a USE L out R 2807, a USE R out L flag 2808 and a USE L in R flag 2809. An operation which is right-friendly has its USE L out R flag 2807 and USE L in R flag 2809 asserted.

Note that flags 2807, 2808 and 2809 are related to the flags in the level activation table 530 that form the alpha channel operation codes the USED_outS, USESoutD and USESROPD flag, as seen in Fig. 18). The USE L out R flag 2807 and the USESout D flags are interoperable, and may be combined into a single flag.

The USE R out L and USED_outS flags may also be combined. However, the flag USE L in R 2809 is only interoperable with the USESROPD flag in the case where the operands of a current level 2800 are both guaranteed to be opaque if the level is active.

When either operand may have an opacity value less than 1, the operation must be performed, and the USE L in R flag 2809 must be set in this case.

Each level entry 2800 has a left/fill counter 2801 and a right counter 2803 for the activity of each branch of the node represented by level 2800. The left/fill counter 2801 acts as a fill counter for levels that are directly activated, and as a left-branch activity flag 702810.doc 72 O for levels that are indirectly activated levels whose activity depends on the activity of o levels in the left branch). In an implementation that takes left-friendliness into account, the left/fill counter 2801 may also be used as a counter for the number of critical contributing levels in the left branch.

M 5 The right-branch counter 2803 indicates the number of active levels in the right r"- 00 branch of level 2800. Counter 2803 is incremented on receiving a signal generated by the (Ni activation of a lower level in the branch.

SField 2817 is a flag that indicates whether the current level 2800 is left friendly.

Each level 2800 also includes two obscurance flags 2805, 2806. The L obscures R flag 2805 indicates that activity of the left branch of node 2800 prevents any contribution from the right branch of the level, thereby obscuring the right branch. Similarly, the R obscures L flag 2806 indicates that activity of the right branch of level 2800 prevents any contribution from the left branch of the level.

When a branch of a node is activated for which an obscurance flag is asserted, the mask counter 2804 is incremented (or flag asserted) in each level in the obscured branch. If the counter or flag 2804 is non-zero, then level 2800 does not contribute an operation to the full priority message 598 passed on to subsequent modules in the pixel sequential renderer The Level is L flag 2813 is set if the level is the top of a left branch.

Flags 2802, 2814 and 2815 are the same as fields already shown in Fig. 18. Flag 2802 is a fill-rule flag. Field 2815 is a fill type, and field 2814 contains operator codes.

Note that some entries in level 2800 are determined by the driver software when the page description is set up, for example the obscurance flags 2805, 2806, the usage flags 2807 2809, the L base IX flag 2810, the R base IX flag 2811 and the ancestor 1X 2812. Other 702810.doc -73- O fields on level 2800 are maintained by the priority update module 506. These fields are o the left/fill counter 2801, the right counter 2803 and the mask counter 2804.

4.3 Maintaining Counters in Level Activation Table n 5 Figs. 30A to 30C illustrate how the priority determination module 500 maintains 00 the counters 2801 and 2803 in the level activation table 530.

(Ni The updating is initiated when the priority determination module 500 receives an edge crossing message 498 from the edge processing module 400. Then, in step 3002, the priority update module 506 checks the direction of the edge direction fields in the edge crossing command 498. If the Up flag is set for the edge (the Yes option of step 3002) then, in step 3003, the priority update module 506 increments the left/fill counter 2801. If the Up flag of the edge is not set (the No option of step 3002) then, in step 3004, the priority update module 506 decrements the left/fill counter 2801.

Once the left/fill counter 2801 has been incremented or decremented as appropriate, process flow proceeds to step 3005, which checks whether the "fill rule is odd-even" flag 2802 is set. Depending on which fill rule is set, the method must check whether the fill counter is odd or, alternatively, whether the fill counter is non zero. If the odd/even fill rule is used (the Yes option of step 3005) then in step 3006 the priority update module 506 checks whether the left/fill counter 2801 is odd. If counter 2801 is odd (the Yes option of step 3006) then process flow proceeds to step 3008. If, however, the left/fill counter 2801 is odd (the No option of step 3006) then process flow proceeds to step 3009.

If the non-zero winding fill rule is used (the No option of step 3005) then, in step 3007, the priority update module 506 checks whether the left/fill counter 2801 is nonzero. If so, (the Yes option of step 3007) then process flow proceeds to step 3008. If, 70281 O.doc 74- O however, the counter 2801 is zero (the No option of step 3007) then process flow 0 proceeds to step 3009.

SIn step 3008, the priority update module 506 checks whether the right counter 2803 is non-zero or whether "both-friendly" is set, i.e. when all three usage flags are M 5 asserted. If the conditions of step 3008 are satisfied (the Yes option of step 3008) then in r- 00 step 3010 the USEL in R flag 2809 is checked. In step 3010, if the USEL in R flag 2809 Sis set, the current level is determined to be an active level 3013. If the USE L in R flag 2809 is not set (the No option of step 3010) then the level is determined as an inactive level 3015.

If the conditions of step 3008 are not satisfied (the No option of step 3008) then in step 3011 the priority update module 506 determines whether the USE L out R flag 2807 is set. In this path of the flow chart, if the flag 2807 is set, then the level is determined to be an active level 3013. However, if the USEL out R flag 2807 is not set (the No option of step 3011), then in step 3014 a right-branch mask-signal is asserted.

The operation of such a mask signal is described in more detail below. In effect, the right-branch mask-signal increments the mask counters 2804 of levels in the right branch below the level activated by the current edge crossing. After asserting the mask-signal in step 3014, the priority update module 506 determines the present level as an inactive level 3015.

The priority update module 506 executes step 3009 if the left/fill counter 2801 is even-(or zero if the non-zero winding fill rule is used). In step 3009, module 506 checks whether the right counter 2803 is non-zero. If the right counter 2803 is zero (the No option of step 3009) then the priority update module 506 determines a present level as an inactive level 3015. In contrast, if the right counter 2803 is non-zero, then step 3012 checks whether the USE R out L flag 2808 has been set. If flag 2808 has not been set (the 702810.doc O No option of step 3012) then the present level is determined as an inactive level 3015. If o the USE R out L flag 2808 has been set (the Yes option of step 3012) then the present level is determined as an active level 3013.

Fig. 30B shows a procedure that is triggered when a level is determined to be an M 5 active level 3013. When the level is determined as active, the priority update module 506 r- 00 checks whether the activity of the level has changed, in step 3020. If the activity of the (Ni Slevel is the same as before (the No option of step 3020) then processing terminates in step S3021. If, however, the activity changed (the Yes option of step 3020) then step 3022 checks whether the ancestor index 2812 is NULL. If the ancestor index 2812 is NULL (the Yes option of step 3022) then processing stops in step 3024. If, however, the present level does have an ancestor node (the No option of step 3022) then in step 3023 the priority update module 506 checks whether the level is L flag 2813 is asserted. If the level is L flag 2813 is asserted (the Yes option of step 3023) then in step 3025 the priority update module increments the left/fill counter 2801 of the ancestor level and the process then ends in step 3024. If the level is L flag 2813 is not asserted (the No option of step 3023) then in step 3026 the priority update module 506 increments the right counter 2803 of the ancestor level and the flow chart terminates in step 3024. Note that in the preferred hardware embodiment step 3026 also increments the right counter of each intervening level. In an alternative software embodiment the right counters of the intervening levels are not incremented.

Fig. 30C shows a flow chart of a procedure triggered when a level is determined as an inactive level 3015. In step 3030 the priority update module 506 checks whether the activity of the level has changed. If there is no change, then process flow terminates in step 3031. If, however, the activity of the level has changed (the Yes option of step 3030), then in step 3032 the priority update module 506 checks whether the ancestor 702810 .doc -76- O index 2812 is NULL. If there is no ancestor to the present level (the Yes option of step S3032) then process flow terminates in step 3034. However, if there is an ancestor node S(the No option of step 3032) then in step 3033 the priority update module 506 checks whether the level is L flag 2813 is asserted. If the level is L flag 2813 is asserted (the Yes option of step 3033) then in step 3035 the priority determination module 506 decrements 00 the left/fill counter 2801 of the ancestor level, and then process flow stops in step 3034.

(Ni SIf the level is L flag 2813 is not asserted (the No option of step 3033) the right counter 2803 of the ancestor level is decremented in step 3036 and process flow terminates in step 3034. Note that in the preferred hardware embodiment step 3036 also decrements the right counter of each intervening level. In an alternative software embodiment the right counters of the intervening levels are not decremented.

Thus, if the level relating to the present edge crossing message is left friendly, the object is activated according to the fill count and fill rule. Note that the operation contributed by such a level still depends on the state of the right branch. However, this contribution can be determined when the priority determination module 500 constructs a fill priority message 598 (also referred to as a PIXEL AT LEVEL command) to be passed down the pipeline to the fill colour determination module 600.

Otherwise, if the level is Lfriendly flag 2817 is not asserted, the state of the right branch is taken into account when the priority update module 506 determines activation.

The state of the right branch is determined by the right counter 2803, which is non-zero if the right branch contains active levels. As may be seen in Fig. 30A, the level is considered active in the following three cases: 1. the USE L out R flag 2807 is set; the left/fill counter 2801 and fill rule 2802 combine to indicate that the left branch object is active; and the right counter 2803 is zero; 702810.doc 77 2. the USE R out L flag 2807 is set; the left/fill counter 2801 and fill rule 2802 O combine to indicate that the left branch object is inactive; and the right counter S2803 is non-zero; and 3. the USE L in R flag 2807 is set; the left/fill counter 2801 and fill rule 2802 M 5 combine to indicate that the left branch object is active; and the right counter r"- 00 2803 is non-zero.

(Ni SNote that the operation that the level contributes is different in each of these three Scases. This difference is accounted for when the priority generation module 516 constructs a fill priority message 598 to be passed down the pipeline to the fill colour determination module 600.

When a current level is activated by the edge received in the edge crossing message 498, then the ancestor level in the table 530 either has its left counter 2801 or right count 2803 incremented, depending on the level is L flag 2813. In the case where the level is L flag 2813 is de-asserted, the levels between the activated level and the ancestor level having the same value of the right base in field 2811 also have their right counters 2803 incremented in the preferred embodiment. If the ancestor LX entry is NULL, then no further levels are activated by the edge in the present edge crossing message 498. NULL ancestors relate, in particular, to entries on the right-most branch of the expression tree representing the page (referred to as the spine). Entries on the spine are those which actually put colour on the page and, because the page is the default background, such entries may be considered to be always right-active.

Fig. 31A shows a flow chart that is triggered 3101 when a left/fill counter or a right counter is incremented, for example by steps 3025, 3026 of Fig. 30B. In step 3103, the priority update module 506 adds one to the left or right counter, as appropriate. Then, in step 3105, module 506 checks whether the left/fill counter 2801 of the level is non-zero.

702810.doc 78 O If so (the Yes option of step 3105), then in step 3107 the module 506 checks whether the o right counter is non-zero. In the case where both the left counter and the right counter are Snon-zero (the Yes option of step 3107) then step 3109 checks whether the USE L in R flag 2809 is set. If the USE L in R flag is set (the Yes option of step 3109) then the level is M€3 5 determined to be an active level 3013. This triggers the process of Fig. 30B for the r"- 00 activated level.

(Ni ~If the USE L in R flag 2809 is not set (the No option of step 3109) then in step 3123 the priority update module 506 asserts the right branch mask signal 3417 and then determines the present level to be an inactive level 3015, triggering the process of Fig.

30C for the present level.

In the case where the left counter is non-zero and the right counter is zero (the No option of step 3107) then step 3113 checks whether the USE L out R flag 2807 is set. If the USE L out R flag is set (the Yes option of step 3113), then the present level is determined to be an active level 3013. If the USE L out R flag 2807 is not set (the No option of step 3113) then in step 3115 the priority update module 506 asserts the left branch mask signal 3533, and the present level is determined to be an inactive level 3015.

When the left counter is non-zero (the No option of step 3105), then in step 3119 the priority update module 506 checks whether the right counter 2803 is non-zero. In the case that both the left and the right counters 2801, 2803 are zero (the No option of step 3119) then the present level is quiescent and in step 3123 the priority update module 506 asserts the right branch mask signal 3417 and determines the present level as an inactive level 3015.

In the case where the left counter 2801 is zero and the right counter 2803 is nonzero (the Yes option of step 3119) then step 3121 checks whether the USE R out L flag 2808 is set. If so (the Yes option of step 3121) then the present level is determined as an 702810.doc 79 O active level 3013. If, however, the USE R out L flag 2808 is not set (the No option of step O 3121) then the right branch mask signal 3417 is asserted in step 3123 and the present level is determined to be an inactive level 3015.

Fig. 31 B shows a flow chart that is triggered 3130 when the left/fill counter 2801 or M 5 the right counter 2803 is decremented, as seen in steps 3035, 3036 of Fig. 30C. Step 3123 r"- 00 subtracts one from either the left/fill counter 2801 or the right counter 2803, as (Ni appropriate.

Then, in step 3134, module 506 checks whether the left/fill counter 2801 of the (,i level is non-zero. If so (the Yes option of step 3134), then in step 3136 the module 506 checks whether the right counter is non-zero. In the case where both the left counter and the right counter are non-zero (the Yes option of step 3136) then step 3138 checks whether the USE L in R flag is set. If the USE L in R flag is set (the Yes option of step 3138) then the level is determined to be an active level 3013. This triggers the process of Fig. 30B for the activated level.

If the USE L in R flag is not set (the No option of step 3138) then in step 3152 the priority update module 506 asserts the right branch unmask signal 3419 and then determines the present level to be an inactive level 3015, triggering the process of Fig.

for the present level.

In the case where the left counter is non-zero and the right counter is zero (the No option of step 3136) then step 3142 checks whether the USE L out R flag 2807 is set. If the USE L out R flag is set (the Yes option of step 3142), then the present level is determined to be an active level 3013. If the USE L out R flag 2807 is not set (the No option of step 3142) then in step 3144 the priority update module 506 asserts the left branch unmask signal 3531, and the present level is determined to be an inactive level 3015.

702810.doc 0 When the left counter is non-zero (the No option of step 3134), then in step 3148 Sthe priority update module 506 checks whether the right counter 2803 is non-zero. In the case that both the left and the right counters 2801, 2803 are zero (the No option of step 3148) then the present level is quiescent and in step 3152 the priority update module 506 asserts the right branch unmask signal 3419 and determines the present level as an 00 0 inactive level 3015.

In the case where the left counter 2801 is zero and the right counter 2803 is nonzero (the Yes option of step 3148) then step 3150 checks whether the USE R out L flag 2808 is set. If so (the Yes option of step 3150) then the present level is determined as an active level 3013. If, however, the USE R out L flag 2808 is not set (the No option of step 3150) then the right branch unmask signal 3419 is asserted in step 3152 and the present level is determined to be an inactive level 3015.

4.3.1 Hardware Implementation of Counter Maintenance Fig. 33 shows a circuit that may be used for updating the right counter 2803 and the left/fill counter 2801 of levels in the level activation table 530. Note that in alternative implementations, the right counter 2803 and left/fill counter 2801 may be updated by software running on a processor such as that found in a general-purpose computer.

Fig. 33 shows, for purposes of explanation, two levels from the level activation table 530. Table entry 3301 represents a current level having a level index 3333 which, in the present example, is set to ZO. Table entry 3303 is the table entry for a level in the same branch as level 3301, but higher up the expression tree. Table entry 3303 has the level index 3335 set to Zn in the present example. The circuit elements 3311, 3317, 3319, 3321, 3323, 3325 and 3342 are used to determine the activity of level 3301 and, based on the determined activity level, to modify the right counter 3327 or the 70281 O.doc -81- O left/fill counter 3344 of level 3303 as appropriate. Each level in the table has a similar set O of circuit elements to determine the state of the counters 2801, 2803 on each level. Note Sthat in the hardware arrangement, since all levels are potentially ancestors, the circuitry to update the counters is present for each level. Thus, when an ancestor level is updated, it M 5 is convenient to update the counters of intervening levels (having the same R base IX) as r"- 00 well. In a software implementation it is not necessary to update the counters of (Ni Sintervening levels, as this adds additional processing operations.

SInformation is conveyed between levels using the buses 3305, 3307 and 3309, the active signal 3313 and the inactive signal 3315. The circuit elements and the buses 3305 3309 are located within the priority update module 506.

When level 3301 is activated, combinatorial network 3311 asserts the "active" signal 3313 and three fields of level 3301 are placed on the buses for one cycle. The current index 3333 is placed on the bus 3307, the R base index 3331 of level 3301 is placed on bus 3305 and the ancestor index 3329 of level 3301 is placed on bus 3309.

Network 3311 is a combinatorial logic network that implements the logic of Fig. If level 3301 is not an ancestor level, then the active signal 3313 is controlled by the fill/left counter and the three usage flags (USE L out R, USE R out L and USE L in R).

The inputs to network 3311 from level 3301 are the left/fill counter, the fill rule flag, the level is left-friendly flag, the right counter, the mask counter, the two obscurance flags and the three usage flags. Level 3301 is active when: The mask count is non-zero, AND The USE L in R flag is set and the left/fill counter is in an active state as determined by the fill rule, and the right counter is non-zero; OR The USE L out R flag is set and the left/fill counter is in an active state as determined by the fill rule and the right counter is zero; OR 702810.doc -82- O The USE R out L flag is set and the left/fill counter is in an inactive state as O determined by the fill rule and the right counter is non-zero.

If level 3301 is determined to be active, then network 3311 asserts the active signal 3313. If level 3301 is not active, network 3311 asserts the inactive signal 3315.

M 5 Note that changes of state caused by the right counter are not propagated, because r"- 00 the ancestor level will already have been activated by the lower level in the right branch of the expression tree.

SFor level 3303, comparator 3319 determines whether the current level 3303 is less (,i than or equal to the ancestor node of level 3301. The ancestor index of level 3301 is available from bus 3309, and the index of level 3303 is available from the current index 3335. The output of comparator 3319 is provided to each of gates 3323 and 3325.

Comparator 3317 checks whether the level index of level 3303 is greater than the level index of level 3301. Comparator 3313 receives the current index of level 3303 from field 3335, and receives the current index of level 3301 from bus 3307. The output of comparator 3317 is provided to each of gates 3323 and 3325.

Comparator 3321 determines whether level 3303 and level 3301 are on the same branch of the expression tree. Comparator 3321 achieves this by determining whether the right base index 3328 of level 3303 is equal to the right base index 3331 of level 3301 that has been placed on bus 3305. The output of comparator 3321 is provided to each of gates 3323 and 3325.

Gate 3325 has four inputs, namely the active signal 3313 and the respective outputs of comparators 3317, 3319 and 3321. If the active signal 3313 is asserted and level 3303 is less than or equal to the ancestor index, greater than the current index and is on the same branch as level 3301, then either the right counter 3327 or the left/fill counter 3344 is incremented, as determined by demultiplexer 3342.

702810.doc 83 O Demultiplexer 3342 receives as inputs the output of gate 3325, the output of gate S3323 and also the LevelisL flag 3340 of level 3303. If the LevelisL flag 3340 is STRUE, i.e. level 3303 is the top of a left branch, then demultiplexer 3342 acts to increment or decrement the left/fill counter 3344. If the Level isL flag 3340 is not M 5 TRUE, then demultiplexer 3342 acts to increment or decrement the right counter 3327.

r- 00 Gate 3323 acts in an analogous way to gate 3325. Gate 3323 acts to decrement the right counter 3327 or the left/fill counter 3344 (as determined by demultiplexer 3342) if the inactive signal 3315 has been asserted.

On an ancestor level, the left/fill counter 2801, the right counter 2803 and the three usage flags 2807, 2808 and 2809 are used to determine whether the ancestor level contributes data. If the ancestor level is contributing data, the process is repeated to update the ancestor(s) of the ancestor. If the ancestor level is not contributing data, then the right branch will be masked.

Masking may be implemented either with a set of mask counters 2804, as described above, or by micro-programmable mask logic, where a programmable gate array is set up by the driver software when the level activation table 2800530 is loaded. In the implementation using mask counters 2804, each level in the right branch below a masking level has the mask counter 2804 incremented when the masking level goes into a forbidden state. Such forbidden states are determined by the usage flags 2807 2809.

When the state of a masking level changes to an active state (as defined by the usage flags 2807 2809 of the masking level), the mask counter 2804 of the levels on the ight branch below the masking level are decremented. The mask counters on the right branch are also decremented when the state of the masking level goes quiescent, i.e. the left/fill counter 2801 and right counter 2803 of the masking level indicate that both branches of the masking level are inactive. Levels with a non-zero mask count 2804 do not contribute an 702810.doc 84- O instruction to the final instruction list 598 that is passed down the pipeline to the fill o coloured determination module 600.

SFig. 34 shows a circuit that may be used to increment or decrement the mask counters 2804. Fig. 34 shows, for explanatory purposes, two levels of the level activation M 5 table 530. The circuitry shown in Fig. 34 determines whether the higher level 3403 r"- 00 affects the mask counter 3405 of the lower level 3401. When the activity of level 3403 is (Ni such that the right branch of level 3403 should be masked, the "mask R" signal 3417 is Sasserted and is provided to gate 3427, which is used to increment the mask counter 3405 of level 3401. Similarly, when the activity of level 3403 indicates that the right branch of level 3403 should be unmasked, the "unmask R" signal 3419 is asserted. The unmask R signal 3419 is provided to gate 3425, which acts to decrement the mask counter 3405 of level 3401.

Unit 3415 determines the activation of the mask R signal 3417 and the unmasked R signal 3419. The inputs to units 3415 are the left/fill counter, the fill rule flag, the level is leftfriendly flag, the right counter, the mask counter, the two obscurance flags and the three usage flags of level 3403. Unit 3415 is a combinatorial logic network that implements the logic of Figs. 31A and 31B.

When the right branch of level 3403 is to be masked, as in steps 3123 or 3152, the L base index 3409 of level 3403 is placed on bus 3411 and the R base index 3407 of level 3403 is placed on bus 3413. For each level, for example level 3401, there are comparators 3421, 3423 that determine whether level 3401 is less than the L base index 3409 and greater than or equal to the R base index 3407 of the masking level 3403.

Comparator 3421 receives the right base index 3407 from bus 3413, together with the current index 3429 of level 3401 and checks that the level 3401 is greater than or equal to 702810 .doc O the base of the branch that is masked by level 3403. The output of comparator 3421 is o provided to each of the gates 3427 and 3425.

SComparator 3423 receives the left base index 3409 of level 3403 from the bus 3411, and determines whether the current level 3429 of level 3401 is less than the left base of the left branch of masking level 3403. The output of comparator 3423 is provided to each 00 of the gates 3425 and 3427.

(Ni Gate 3427 receives and inputs the mask R signal 3417 and the outputs of Scomparators 3421 and 3423. If the mask R signal 3417 is asserted and the two conditions set by the comparators are satisfied, then gate 3427 acts to increment the mask counter 3405.

Gate 3425 acts in an analogous manner to decrement the mask counter 3405 when the masking condition of level 3403 changes such that level 3403 no longer masks lower levels. Thus, if the conditions imposed by comparators 3421 and 3423 are satisfied and the unmask R signal 3419 is asserted, then the mask counter 3405 is decremented.

Fig. 35 shows a circuit that may be used for masking the left branch of masking level 3501. As before, two levels 3501, 3503 of the level activation table 530 are shown for explanatory purposes. Similar circuitry is applied to each of the levels in table 530.

When the activity of level 3501 is such that the left branch of level 3501 is to be masked, as in steps 3115 or 3144, then the current index 3509 of level 3501 is placed on bus 3511 and the left base index 3507 of level 3501 is placed on bus 3513. The information placed on buses 3513 and 3511 is available to the other levels in table 530, for instance level 3503. Unit 3508 determines whether the activity of level 3501 requires the left branch to be masked. The inputs to unit 3508 are the left/fill counter, the fill rule flag, the level is leftfriendly flag, the right counter, the mask counter, the two obscurance flags and the three usage flags of level 3501. As appropriate, unit 3508 will assert the 702810.doc -86- O "mask L" signal 3533 or the "unmask L" signal 3531. Unit 3508 is a combinatorial logic O network that implements the logic of Figs. 31A and 31B. The current index 3519 of level S3503 is provided to each of comparators 3515, 3517. Comparator 3515 determines whether the current index 3519 of level 3503 is greater than or equal to the base of the left M€ 5 branch of level 3501, which is available from bus 3513. The output of comparator 3515 r"- 00 is provided to each of gates 3521 and 3523.

The comparator 3517 checks that the current index of level 3503 is less than the Scurrent index of the masking level 3501, which is available from bus 3511. The output of comparator 3517 is provided to each of gates 3521 and 3523.

When the mask L signal 3533 is asserted and the conditions implied by comparators 3515 and 3517 are satisfied, then gate 3521 acts to increment the mask count 3505 of level 3503. Analogously, when the unmasked L signal 3531 is asserted and the conditions of comparators 3515 and 3517 are satisfied, then gate 3523 acts to decrement the mask counter 3505 of level 3503.

Note that buses 3305 3309 for level activation and buses 3511, 3513, 3411, 3413 for masking can be shared, with a suitable bus protocol to prevent contention. Three buses are sufficient for all purposes. Note that the left base index 2810 is used both in right-branch masking and in left-branch masking.

4.4 Command Generation Fig. 36 shows a flow chart of a method for constructing pixel commands that are passed down the pipe line to the fill colour determination module 600. The procedure for constructing pixel commands is implemented by the priority generation module 516.

Using the left/fill counter 2801, the right counter 2803 and the mask counter 2804, the priority generation module 516 is able to read the instruction and fill data in the 702810 .doc -87- O contributing levels, reading from bottom to top. The command generation procedure O makes use of an Rbase level index. Whenever the Rbase level index increases, the procedure replaces the instruction in the current level by a stack PUSH. To determine whether a current level contributes, the priority generation module 516 checks that the M€3 5 level is active and is not masked.

r"- 00 t' In an implementation where the mask is a logic signal generated by a field- (Ni Ni- programmable gate array, programmed with the dependencies determined by the Sexpression tree, then the mask signal is inverted and ANDed with the activity state of the current level to determine whether the current level contributes. In the preferred implementation when the dependencies of the expression tree are maintained by the counter mechanism of table 530, the activity state of the current level (eg. active signal 3313) is ANDed with a signal obtained by comparing the right counter 2803 of the current level with zero. Such procedures to determine whether a level is a contributing level are used in steps 3614 and 3628 of the method of Fig. 36.

The method 3610 for constructing pixel commands commences in step 3612, in which an Rbase register is initialised to zero. Then, in step 3614, the first contributing level is determined by one of the mechanisms described above. Next, in step 3616 the Rbase index 2811 of the contributing level is compared against the contents of the Rbase register. If the Rbase level of the contributing level is greater than the value in the Rbase register (the Yes option of step 3616) this indicates that the contributing level is the first active level of a new branch. In this case, in step 3621 a PUSH operation is appended to the PIXEL AT LEVEL command that is to be sent onto the fill colour determination unit 600. Once the PUSH operation has been appended, process flow proceeds to step 3622.

If the Rbase index of the current contributing level is not greater than the value in the Rbase register (the No option of step 3616) then process flow proceeds to step 3618, 702810.doc 88- O which checks whether the specified stack operation in the current contributing level is a O POP SOURCE and the right count of the current contributing level is zero or rightmasked. If these conditions are satisfied the Yes option of step 3618) then no operations are appended to the PIXEL AT LEVEL command and process flow proceeds directly to 5 step 3622. If, however, the conditions of step 3618 are not satisfied, (the No option of 00 r- step 3618) then process flow proceeds to step 3620 in which the operation specified in the (Ni current contributing level is appended to the PIXEL AT LEVEL command. Process flow then proceeds to step 3622.

Note that a decrease in the value of Rbase is associated with a POP operation, which is also treated as a special case. Because an operation which obtains its result by combining a source value popped off the stack with a destination value obtained from the top of the stack (after the POP), there is a possibility that such might cause a stack underflow if the POP is performed when there has been no destination value constructed.

Thus, the POP should only be performed if the right-activity counter is non-zero for the operation. The test in step 3618 ensures that no operation is included in the pixel AT LEVEL command for a contributing level that includes a stack pop operation, if the right counter of the contributing level is zero.

Step 3622 checks to see whether there are any higher priority levels in table 530 that are contributing. If there are no higher priority levels in table 530 that are contributing (the No option of step 3622) then in step 3624, an END OF PIXEL marker is appended to the PIXEL AT LEVEL command. The PIXEL AT LEVEL command is then ready for forwarding to the next module 600 in the pipeline.

If there are higher priorities in table 530 that are contributing (the Yes option of step 3622) then in step 3626 the Rbase index of the current contributing level is saved in the 702810.doc 89- CRbase register. Then, in step 3628, the next contributing level is obtained from table 530 U) and process flow returns to step 3616 to process the next contributing level.

In the embodiment of the pixel-sequential renderer 20 using the table optimization of Section 4.0, some of the units of the priority determination module 500 are redundant.

In particular, the Opaque Flag Store 510 and the priority encoder 514 are not utilised 00 F because the masking mechanism described above ensures that objects below an opaque object are inactive. The priority generation module 516 determines the lowest unmasked Npriority and the active levels from the table 530.

4.5 Example Fig. 29A shows a small expression tree 2900 and Fig. 29B shows the equivalent of expression tree 2900 when transposed into the linearised table form 2902. In table 2902, entries marked with an x must contain a valid value for the Fill Rule and the Fill Type fields. These values determine properties of the objects represented in the expression tree, rather than properties of the expression tree, and are thus not required for the purposes of the present example. Entries in table 2902 marked with a dash are ignored by the system. In particular, the Fill Rule and Fill Type fields are not required for entries which are indirectly activated, and the Level isL flag is not used for objects that do not propagate an activation state up the tree.

The topmost node in expression tree 2900 is an OVER operation W15. In the right branch of the tree 2900 there is an OVER operation W10 that has a left leaf node W101 and a right leaf node WOO. The white background page is node WOO, which is shown in broken outline as it does not require an entry in table 2902 since the system takes advantage of the fact that the default output of the pixel compositor is opaque white.

7028|0.doc Thus, 'page' can be assumed to be always active. Nodes W15 and W10 are on the spine O of the tree 2900.

SThe topmost node in the left branch of node W15 is the CLIP operation W14, which has a right branch consisting of an OVER operator W13, then an OVER operator 5 W12 and finally a PUSH operator Wi 1, which is the base node of the branch including 00 r- W1 l-W14. Operator W11 has a left leaf node W111, operator W12 has a left leaf node W121 and operator W13 has a left leaf node W131. The CLIP operator W14 has a left leaf node W141 shown in broken outline as the CLIP object does not itself appear on the page and thus does not require instructions to be generated for the fill colour determination module 600. Objects W11, W12 and W13 have their L obscures R flags set.

Starting at the bottom of the tree 2900 (and the table 2902), operation W10 is on the spine of the tree, and the left operand of W10 is a leaf node W101, so that the entry in the table 2902 includes afill type index for the fill, W101, and the operation OVER. Because node W10 is on the spine, the Ancestor IX field of W10 is set to NULL, indicating that further propagation of activation state is not necessary when this node is activated. The L base IX field in table 2902 for the level corresponding to node W10 is set to NULL, indicating that the level is directly activated. The R base IX field for level is set to NULL, indicating that the operation on node W10 may be performed with the default background.

The next object in Z order is the clip, W14. However clips are applied at the root of a sub-branch in this system, so that the driver software should keep the clipping object until all of the objects Wi1-13 affected by clip W14 have been loaded into table 2902 before loading the clip level W14 into the table. In most printer interfaces, the extent of a clip is not known until the final clipped object has been loaded and the clip closed.

702810.doc -91 SThe next object to be loaded into the table 2902 is W 1, which is a PUSH U operation, to create a new branch for the objects being clipped. The ancestor of the branch is the clipping object W14, so level W14 is loaded into the Ancestor IX field of level W11. Level W 11 lies in the right branch of W14, so the Level isL flag for level W 11 is clear. The L base IX field is set to NULL, indicating that level W1 1 is directly 00 activated, and the R base IX is set to W 1, indicating that this node is the base node of the (Ni current branch.

N Objects W12 and W13 are the next to be loaded into table 2902. Both W12 and W13 are OVER operations that are clipped by level W14. Note that if object Wl is inactive, and either of levels W12 or W13 is contributing, the active level W12 or W13 will be replaced by a PUSH operation in the command generation procedure as shown in Fig. 36. Note also, that the command generator can identify that a PUSH is required by checking the R base IX field. An increase in R base IX as the command generator steps up through the table 2800530 indicates a stack push, while a decrease in R base IX indicates a pop. In table 2902 levels W12 and W13 have W11 as the R base IX and W14 as the Ancestor IX.

The next object to be loaded into table 2902 is the clip W14. A clip object never contributes colour, or any operation to the output, but it can prevent other levels from providing colour. The example shown in the table 2902 is a directly activated clip in.

Note the settings of the usage and obscurance flags: the R obscures L flag is set for level W14, preventing the left branch contribution and performance of any operation when an object in the right branch is active. The Use L in R flag is the only usage flag set for level W14, so that the right branch operations only contribute when the left branch is active.

The Use R out L flag is de-asserted, so that when the right branch of level W14 is active without the left branch being active, the levels in the right branch are masked.

702810 .doc 92 O For example, if level W14 is right-activated by any of the levels in its right branch o WI l-W13 without being directly left-activated, right count is non-zero and left/fill Scount is zero), then, because the Use R out L flag of level W14 is de-asserted, all of the levels W I-W13 in the right branch have their mask count incremented. All levels from the level immediately below the left base down to the right base are masked. Because 00 r- W14 is directly activated, the level immediately below the left base is level W13; thus

C',

levels W13 down to Wi1 are masked. When level W14 is directly activated (by Sreceiving an edge crossing message) the same mask counts are decremented. If level W14 falls inactive (ie both right and left/fill counts are zero), the mask counts of levels W ll-W13 are also decremented. This means that the mask counts in table 2902 can be initialised to zero, simplifying the table loader's task.

Level W14 has its Ancestor IX value set to W15, and the Level is L flag of level W14 is set, indicating that W14 increments the left counter of W15 when level W14 becomes active.

The final level is W15, the level which contains the instruction to composite the result of this branch onto the background page. The L Base IX value of level W15 is set to W 11, which means that level W 15 is not directly activated. Level W 15 is activated by level W14 when W14 is left-activated by the edges of level W14 and right-activated by any of the levels W1i i-W13. The R base IX value of level W1 5 is NULL, indicating that the operation of level WI 5 may be performed with the default background. The Ancestor IX value of level W15 is also set to NULL, indicating that no further propagation of activation state is to be performed.

The objects of Fig. 32 are now used to illustrate what happens when levels in table 2902 are activated. Fig. 32 shows a triangular clipping object corresponding to level W14, a rectangular object corresponding to level W13, a square object corresponding to 702810 .doc -93- O level W12 and a polygon corresponding to level W11. For illustrative purposes, a single 0 scanline T01 is shown, intersecting object W12 at positions Xtl and Xt8, intersecting the clipping object W14 at positions Xt2 and Xt6, intersecting the object W13 at positions Xt3 and Xt5 and intersecting object W11 at positions Xt4 and Xt7. Positions Xtl-Xt8 are S 5 ordered sequentially along scanline T01.

The levels in table 2902 are applied to the objects in Fig. 32 as follows. All levels i in table 2902 are initially deactivated, and level W12 is activated by an edge crossing N message indicating position Xtl, using the process of Fig. 30A. The Priority determination module 500 generates a PIXEL AT LEVEL command 598 corresponding to the messages shown in Fig. 22A, to pass to the fill colour determination module 600 and the pixel compositing module 700, instructing them to fill all pixels in scanline T01 prior to Xtl with the default background colour. Module 500 then adjusts the state of the table 2902 as follows, using the process of Fig. 30B: the Ancestor IX value of the activated level W12 is W14, and the Level is L flag of level W12 is de-asserted, and therefore the right counter is incremented in level W14. This puts W14 into a state where the right branch is to be masked since the left branch of W14 is not active, so the mask signal is asserted on levels W13 down to W1l (the base of the right branch of W14), incrementing the mask count in levels W13 down to W11. Level W12 is therefore masked, and so does not contribute an instruction to pixels in the interval before the next edge crossing.

Next, the clipping object of level W14 is left-activated by an edge crossing at position Xt2. The Priority determination module 500 generates a PIXEL AT LEVEL command 598 to the downstream modules 600 and 700 containing instructions to fill all pixels in the range Xtl to Xt2 with colour from the contributing levels. In this case, no levels were contributing since level W12 is masked by W14, and W14 makes no 702810.doc 94 O contribution between Xtl and Xt2 because of the obscurance and usage flag settings of O W14. This PIXEL AT LEVEL command therefore instructs the downstream modules to fill the pixels between Xtl and Xt2 with the default colour.

The priority determination module 500 then adjusts the state of the table 2902 as M 5 follows: level W14 is activated, because the right counter of level W14 is non-zero, the r'- 00 fill count and fill rule determine that it is left-active, and the Use Lin R flag is set. The (Ni right branch is unmasked, so the unmasking signal is asserted on levels W13 down to W W11, allowing level W12 to contribute data. Because the RobscuresL flag in W14 is set, W14 does not itself contribute an instruction. The Ancestor IX value in W14 is and the LevelisL flag is of W14 is asserted, and therefore the left counter is incremented in W15. Because W15 is right-friendly, this activates W15. However, has its L obscures R flag set, which asserts the masking signal to the right branch of W on levels W 10 (immediately below L base) down to the bottom of the table 2902 (because R base NULL). This also means that W15 does not contribute an operation at step 3618 of the command generation, as level W 15 is a pop with no corresponding push.

The next edge encountered is the edge of object W13 at Xt3. The Priority determination module 500 generates a PIXEL AT LEVEL command to send to modules 600 and 700 with instructions to fill all pixels of scanline T01 in the range Xt2 to Xt3 with colour from the contributing levels. In this range, level W12 contributes an operation. When the priority determination module 500 reads contributing levels (eg in step 3614 of Fig. 36), module 500 uses the R base field to determine the branch in which the contributing level resides. In the command generation, module 500 replaces the first contributing operation in each branch with a stack PUSH (step 3616). The first contributing operation in a branch is indicated by an increase in R base. Therefore, in the present example, the W12 operation is replaced by a PUSH operation. Since W12 is the 702810.doc only contributing operation between Xt2 and Xt3, a PIXEL AT LEVEL command is O generated for this range ofpixels, containing the PUSH W121 operation.

The table 2902 is then modified as follows: W13 is activated directly by the edge, and because the L obscures R flag of level W13 is set, a masking signal is asserted for levels W12 and W11, incrementing their mask counters. The Ancestor IX value in level 00 F W13 is W14, and its Levelis L flag is de-asserted, and therefore the right counter is incremented in level W14. This does not change the state of W14, so no further action is taken.

The next edge encountered is the edge of object Wi1 at Xt4. The Priority determination module 500 generates a PIXEL AT LEVEL command to send to the downstream modules with instructions to fill all pixels in the range Xt3 to Xt4 with colour from the contributing levels. This time, levels W12, W13, W14 and W15 are active, but only level W13 contributes an operation. When the priority determination module 500 reads contributing levels, it uses the R base field to determine the branch in which the level resides, and replaces the first contributing operation in each branch with a stack PUSH. The first contributing operation in a branch is indicated by an increase in R base; therefore the W13 operation is replaced by a PUSH operation. This being the only contributing operation between Xt3 and Xt4, a PIXEL AT LEVEL command is generated for this range of pixels, containing the PUSH W131 operation.

The table 2902 is then modified as follows: W11 is activated directly by its edges.

The Ancestor IX value in W I is W14, and the Level isL flag of W 1 is de-asserted, so the right counter is incremented in levels W11-14. This does not change the state of the ancestor level W14, so no further action is taken.

Note that in prior art pixel sequential renders, the change of state of level W11 would have required action on each of the intervening levels, W12 and W13. Because 702810.doc -96- O these are not ancestor levels, no action is taken on levels W12 and W13 in the present Sarrangement.

The next edge encountered along scanline T01 is the edge of object W13 at The Priority determination module 500 generates a PIXEL AT LEVEL command to the downstream modules with instructions to fill all pixels in the range Xt4 to Xt5 with colour 00 F from the contributing levels. This time, level W11, W12, W13, W14 and W15 are active, (Ni but only level W13 contributes an operation because of the obscurance flag settings.

SWhen reading contributing levels, the priority determination module 500 uses the R base field to determine the branch in which the level resides, and replaces the first contributing operation in each branch with a stack PUSH. The first contributing operation in a branch is indicated by an increase in R base; therefore the W13 operation is replaced by a PUSH operation. This being the only contributing operation between Xt4 and Xt5, a PIXEL AT LEVEL command is generated for this range of pixels, containing the PUSH W131 operation.

The table 2902 is then modified as follows. Level W13 is de-activated directly by the edge at Xt5. Because the L_obscuresR flag of level W13 is asserted, the unmasking signal is asserted for levels in the right branch of W13, decrementing the mask counts in W12 and W11. W12 still masks W11, however, so W12 is the sole contributing level.

The Ancestor IX value in W13 is W14, and the Level is L flag of level W13 is deasserted, and therefore the right counter is decremented in level W14. This does not change the state of W14, so no further action is taken.

The next edge encountered is the edge of object W14 at position Xt6. The Priority determination module 500 generates a PIXEL AT LEVEL command to the subsequent modules with instructions to fill all pixels in the range Xt5 to Xt6 with colour from the contributing levels. This time, level W11, W12, W14 and W15 are active, but only level 702810 .doc -97- W12 contributes an operation. When the priority determination module 500 reads O contributing levels, it uses the R base field to determine the branch in which the level resides, and replaces the first contributing operation in each branch with a stack PUSH.

The first contributing operation in a branch is indicated by an increase in R base; e 5 therefore the W12 operation is replaced by a PUSH operation. As this is the only 00 contributing operation between Xt5 and Xt6, a PIXEL AT LEVEL command is generated (Ni for this range ofpixels, containing the PUSH W121 operation.

SThe table 2902 is then modified. The left counter of level W14 is decremented directly by the edge at Xt6, and falls to zero. Because the R out L flag in W14 is deasserted, the level is deactivated, and the masking signal is asserted in the right branch of level W14, incrementing the mask counts in levels W13 down to W1 1. The Ancestor IX value in W14 is W15, and the Level isL flag of W14 is asserted, thus the left counter is decremented in level W15S. This de-activates level W15, so the unmasking signal is asserted in the right branch of W15, namely the levels W10 down to the base of the table 2902. The Ancestor IXvalue of W15 is NULL, so no further action is taken.

The next edge encountered is the edge of object W1 at Xt7. The Priority determination module 500 generates a PIXEL AT LEVEL command to the downstream modules, instructing the downstream modules to fill all pixels in the range Xt6 to Xt7 with colour from the contributing levels. This time, levels W 11 and W12 are active, but masked, and so no level contributes an operation. The PIXEL AT LEVEL command to generate default pixels is generated for this range.

Table 2902 (also known as the priority determination table) is then modified as follows. The left counter W11 is decremented directly by the edge at Xt7, and falls to zero. This deactivates the level W 1. The Ancestor IX value in W 1 is W14, and the Level isL flag of W 11 is de-asserted, and thus the right counters are decremented in 702810.doc -98- O levels W12-W14. This does not affect the activity of level W14, so no further action O takes place.

aThe next edge encountered is the edge of object W12 at Xt8. The Priority determination module 500 generates a PIXEL AT LEVEL command to the downstream modules, instructing them to fill all pixels in the range Xt7 to Xt8 with colour from the 00 contributing levels. This time, level W12 is active, but masked, and no level contributes an operation. The PIXEL AT LEVEL command to generate default pixels is generated N for this range.

Table 2902 is then modified as follows. The left counter in level W12 is decremented directly by the edge at position Xt8, and falls to zero. This deactivates the level W12. The Ancestor IX value in W12 is W14, and the LevelisL flag of W12 is deasserted, so that the right counter is decremented in levels W13-W14. The right counter value in W14 falls to zero, so the unmasking signal is asserted on levels W13 down to W1 I. This does not affect the activity of level W14, so no further action takes place.

The next message from the Edge Module 400 is an END OF SCANLINE command. This causes the Priority determination module 500 to generate a PIXEL AT LEVEL command for the remaining pixels in the scanline. Because no object remains active, this command is for a run of default pixels.

The aforementioned processes implemented by the computer system 1 comprise a particular control flow. There are many other variants of the described processes, which use different control flows without departing from the spirit or scope of the invention.

Furthermore one or more of the steps of the described method(s) may be performed in parallel rather than sequentially.

INDUSTRIAL

APPLICABILITY

702810.doc 99 O It will be apparent from the above that the arrangements described are applicable O to computer graphics and printing industries.

SThe foregoing describes only some arrangements of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the arrangements being illustrative and not restrictive.

00 r (AUSTRALIA ONLY) In the context of this specification, the word 4 "comprising" means "including principally but not necessarily solely" or "having" or S"including" and not "consisting only of'. Variations of the word comprising, such as "comprise" and "comprises" have corresponding meanings.

702810.doc

Claims (4)

1. A method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of: 5 storing a hierarchical description of said image, said description being arranged in a 00 plurality of levels from a lowest level to a highest level, each level being descriptive of a C, corresponding object, said levels being grouped in one or more branches, each said ,I branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range ofpixels; identifying as contributing levels those active levels that are not masked, wherein said identifying step considers the levels of the description in sequence from lower levels to higher levels.

2. A method as claimed in claim I wherein each level specifies an operation and the method comprises the step of: appending, for a current contributing level, the corresponding operation to a command sequence.

3. A method as claimed in claim 2 wherein if said current contributing level is the lowest contributing level of a branch, a PUSH operation is appended to said command sequence.

702810.doc -101- O

4. A method as claimed in any one of the previous claims wherein if said determining step determines that a current level is active, said updating step updates the counters on all levels on the same branch between said current level and the ancestor level of the current level. 00 (Ni A method as claimed in claim 1 wherein said hierarchical description is a tabular representation of an expression tree having one or more binary nodes and a plurality of leaf nodes, each binary node having a left branch to a descendent node and a right branch to a descendent node and representing a binary operation on said two descendent nodes, each node representing a graphic object, with one or more said graphic objects overlapping, each said overlapping graphics object comprising a left node region, a common region and a right node region and wherein each said level comprises usage flags that indicate which of said regions of a corresponding node contain data when either of said left branch and said right branch is active. 6. A method as claimed in claim 5 wherein said counter comprises a right counter that indicates the number of active levels in said right branch and a left/fill counter that indicates an activity state of said left branch. 7. A method as claimed in claim 6 wherein said determining step determines whether a current level is active based on said usage flags, said right counter and said left/fill counter. 702810 .doc -102- S8. A method as claimed in claim 1 wherein at least one ancestor level has a further o ancestor level and, if said counter of said at least one ancestor level is incremented and said at least one ancestor level is a contributing level, said counter of said further ancestor level is incremented. 00 9. A method as claimed in claim 5 wherein said expression tree is a right-biased tree and said objects are activated by edges intersecting said scanline. Apparatus for identifying contributing objects on a scanline of an object-based image to be rendered, said apparatus comprising: means for storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; means for determining levels that are active for a range of pixels on the scanline; means for updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; means for masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; means for identifying as contributing levels those active levels that are not masked, wherein said means for identifying considers the levels of the description in sequence from lower levels to higher levels. 11. A system for identifying contributing objects on a scanline of an object-based image to be rendered, said system comprising: 702810.doc 103 Sa storage unit for storing a hierarchical description of said image, said description O being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; 00 a processing circuit for determining levels that are active for a range of pixels on the scanline; (a processing circuit for updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; a masking circuit for masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; and a processor for identifying as contributing levels those active levels that are not masked, wherein said processor considers the levels of the description in sequence from lower levels to higher levels. 12. A computer program comprising machine-readable program code for controlling the operation of a data processing apparatus on which the program executes to perform a method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of: storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; 702810.doc 104 updating said counter, for an ancestor level of each said branch, to indicate the O number of active levels in said branch; masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; identifying as contributing levels those active levels that are not masked, wherein 00 said identifying step considers the levels of the description in sequence from lower levels (Ni to higher levels. 13. A computer program product comprising machine-readable program code recorded on a machine-readable recording medium, for controlling the operation of a data processing apparatus on which the program code executes to perform a method for identifying contributing objects on a scanline of an object-based image to be rendered, said method comprising the steps of: storing a hierarchical description of said image, said description being arranged in a plurality of levels from a lowest level to a highest level, each level being descriptive of a corresponding object, said levels being grouped in one or more branches, each said branch having an ancestor level, wherein each level comprises a counter; determining levels that are active for a range of pixels on the scanline; updating said counter, for an ancestor level of each said branch, to indicate the number of active levels in said branch; masking the levels in a branch if the counter of the ancestor level of the branch is non-zero but said ancestor level does not contribute to said range of pixels; identifying as contributing levels those active levels that are not masked, wherein said identifying step considers the levels of the description in sequence from lower levels to higher levels. 702810.doc 105- 14. A method substantially as described herein with reference to the embodiments as illustrated in Figs. 25 36. 15. An apparatus substantially as described herein with reference to the embodiments as 00 illustrated in Figs. 25 36. 16. A system substantially as described herein with reference to the embodiments as illustrated in Figs. 25 36. 17. A computer program substantially as described herein with reference to the embodiments as illustrated in Figs. 25 36. 18. A computer program product substantially as described herein with reference to the embodiments as illustrated in Figs. 25 36. DATED this Tenth Day of December, 2004 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON FERGUSON 702810.doc