AU2005244588A1 - Method and apparatus for rendering rectangular blocks in a 2D graphics rendering system - Google Patents

Description

S&FRef: 731955

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 3-chome, Ohta-ku, Tokyo, 146, Japan Geoffrey Bruce Bull Tjoan Kok Lie Cormac Brick Benjamin Michael Lever David Eric Humphrey Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Method and apparatus for rendering rectangular blocks in a 2D graphics rendering system The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5845c O METHOD AND APPARATUS FOR RENDERING RECTANGULAR ("i BLOCKS IN A 2D GRAPHICS RENDERING

SYSTEM

FIELD OF INVENTION 00 oO 00 The current invention relates to the rendering of object graphic elements into raster pixel images and in particular to generating rectangular block-shaped regions of the image.

BACKGROUND

Many rendering methods have been developed that allow high level descriptions of 2D images to be converted into pixel data. These rendering methods are often used in such devices as printers and video graphics display systems.

In some systems, it is also desirable to compress the resultant, rendered pixel data.

One popular technique is to use JPEG compression. Some compression methods such as JPEG are known as block-based compression techniques. This means they operate on small rectangular regions of pixel data at a time, typically blocks of 8 x 8 pixels.

In some systems, pixel data is rendered to a frame buffer. In such systems, delivery of pixel blocks to a compressor is simple as pixel data can be read from the frame buffer a block at a time.

In other systems, pixel data is instead rendered in pixel-sequential or raster order to a scanline buffer. If a scanline-based rendering system was required to deliver pixel blocks, one technique would be buffering N scanlines of pixel data, where N is the height of a block. Once N scanlines are buffered, pixel data can be read a block at a time. The disadvantage of this method is that the storage required for buffering an extra N 1 scanlines of pixel data can be expensive.

731955.doc

O

SUMMARY

SThe present invention addresses the problem of rendering pixel data in block order IDwithout the expense of buffering N lines of pixel data.

According to a first aspect of the invention there is provided a method of rendering 00 00 5 one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said method comprising the steps of: traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order.

According to a second aspect of the invention there is provided a method of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object defined by object edges and fill data, said method comprising the steps of: traversing scanlines that overlap the block; identifying regions on the traversed scanlines that lie between adjacent object edges; storing region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; 731955.doc determining stored region commands relating to pixels within the block; Sand ID computing a colour of pixels within the block using the determined region commands and related fill data.

00 00 5 According to a further aspect of the invention there is provided an apparatus for rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said apparatus comprising: means for traversing scanlines that overlap the block; means for buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; means for determining buffered commands relating to the colour of pixels within the block; means for computing the colour of pixels within the block using the determined commands and the fills; and means for outputting the computed colour of the pixels in the block in scanline order.

According to a further aspect of the invention there is provided an apparatus for rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object defined by object edges and fill data, said apparatus comprising: means for traversing scanlines that overlap the block; means for identifying regions on the traversed scanlines that lie between adjacent object edges; 731955.doc means for storing region commands corresponding to the identified

U

Sregions, the region commands identifying objects that are active in the corresponding IND region and a span of pixels lying within the region; means for determining stored region commands relating to pixels within 00 00 5 the block; and means for computing a colour of pixels within the block using the In determined region commands and related fill data.

According to a further aspect of the invention there is provided a system for rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, said system comprising: memory storing object information, each object comprising edge data and a fill, said memory further buffering commands relating to the colour of pixels to be rendered along the scanlines; and a processor in communication with said memory and configured to implement the steps of: traversing scanlines that overlap the block; buffering commands in said memory relating to the colour of pixels to be rendered along the traversed scanlines, using the edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order.

731955.doc SAccording to a further aspect of the invention there is provided a computer Sprogram product comprising machine-readable program code recorded on a machine- INO readable recording medium, for controlling the operation of a data processing apparatus on which the program code executes to perform a method of rendering one or more 00oO 00 5 graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said method comprising the steps of: traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order.

According to a further aspect of the invention there is provided a computer program product comprising machine-readable program code recorded on a machinereadable recording medium, for controlling the operation of a data processing apparatus on which the program code executes to perform a method of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object defined by object edges and fill data, said method comprising the steps of: traversing scanlines that overlap the block; identifying regions on the traversed scanlines that lie between adjacent object edges; 731955.doc storing region commands corresponding to the identified regions, the (region commands identifying objects that are active in the corresponding region and a ND span of pixels lying within the region; determining stored region commands relating to pixels within the block; 00 00 5 and computing a colour of pixels within the block using the determined region 0 commands and related fill data.

According to a further aspect of the invention there is provided a computer program comprising machine-readable program code for controlling the operation of a data processing apparatus on which the program code executes to perform a method of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said method comprising the steps of: traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order.

According to a further aspect of the invention there is provided a computer program comprising machine-readable program code for controlling the operation of a data processing apparatus on which the program code executes to perform a method of rendering one or more graphical objects within a block of a pixel-based image comprising 731955.doc a plurality of scanlines, each object defined by object edges and fill data, said method Scomprising the steps of: O traversing scanlines that overlap the block; identifying regions on the traversed scanlines that lie between adjacent 00 00 5 object edges; storing region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; determining stored region commands relating to pixels within the block; and computing a colour of pixels within the block using the determined region commands and related fill data.

BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the present invention will now be described with reference to the following 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 of Fig. 1; 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 diagram showing the data flow within the pixel-sequential rendering apparatus according to a first arrangement; 731955.doc Fig. 5 is a diagram showing an illustrative example of the serpentine flow of buffering edge crossing commands according to the first arrangement; Fig. 6 is a diagram showing region commands being loaded sequentially into one of eight region line buffers according to a second arrangement; 00 00 5 Fig. 7 is a diagram showing the state of the region line buffers, region line buffer pointers, and X counters at the start of region reordering in an illustrative example of the second arrangement; Fig. 8 A to 8C illustrate, in sequence, the outputting of three region commands from the region buffer of the first scanline within the first block of a row; Fig. 9 A and 9B illustrate the truncation of a region command that spans a block boundary; Fig. 10 A shows the final region command of the first block in a row being output; Fig 10 B shows the final region command of the final block in a row being output; Fig. 11 is a diagram showing the data flow of region commands into separate RSA and RCLL buffers according to a further arrangement.

DETAILED DESCRIPTION INCLUDING BEST MODE Fig. 1 illustrates schematically a computer system 1 configured for rendering and presenting computer graphic object images. The system 1 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, which operate in raster fashion.

731955.doc O 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 \Othe art, such as IBM PC/AT type personal computers and arrangements evolved therefrom, Sun Sparcstations and the like.

00 00 5 Also seen in Fig. 1, a pixel sequential rendering apparatus 20 (or renderer) connects to the bus 9, and is configured for the sequential rendering ofpixel-based images Sderived from graphic object-based descriptions supplied with instructions and data from the host processor 2 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 associated therewith a dedicated rendering store arrangement 30, typically formed of semiconductor RAM. In one arrangement the pixel sequential rendering apparatus 20 is a software module running on the host processor 2. The rendering apparatus 20 may alternatively be a separate unit, implemented either in hardware or as a software module running on a separate processor (not shown).

Image rendering operates generally speaking in the following manner. For ease of explanation the location 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. A software program, 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 thirdparty 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.

731955.doc 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.

00 00 5 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 400. Partitioned edges are N sorted by the X-value of their starting positions and then by Y. Groups of edges 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 400 when rendering reaches that Y-value.

The driver software sorts the operations, associated with painting objects, into priority order, and generates instructions to load a data structure (the level activation table) associated with the level activation module 600. This structure includes a field for the fill 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 900 is indexed by the data structure associated with the level activation module 600. This allows several levels in the level activation module 600 to refer to the same fill data structure.

731955.doc 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 IND 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 00 00 5 of the rendering system and its memory.

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 description 11 which is used to describe those parameters of graphic objects in a fashion appropriate to be generated by the host processor 2 and/or, where appropriate, stored within 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 images. For example, the object graphic description 11 may incorporate objects with edges in a number of formats including straight edges (simple vectors) that traverse from one point on the display to another, or an orthogonal edge format where a twodimensional 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.

731955.doc Having identified the data necessary to describe the graphic objects to be rendered, the graphic system 1 then performs a display list generation step 12.

IThe 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 00 00 5 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 100, another being edge information 300 and where appropriate, raster image pixel data 1000.

The instruction stream 100 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.

The display list store 13 is read by the pixel sequential rendering apparatus The pixel sequential rendering apparatus 20 may be 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.

Fig. 3 shows the configuration of the pixel sequential rendering apparatus 20, the display list store 1400 and the temporary rendering stores 1600. The processing stages 1500 of the pixel-sequential rendering apparatus 20 include an instruction executor 731955.doc -13module 200, an edge processing module (EM) 400, a level activation module (LAM) 600, U a fill colour generation module 800, a pixel compositing module 1100, and a pixel output ND module 1300. The processing operations use the temporary stores 1600 which, as noted above, may share the same device (eg. magnetic disk or semiconductor RAM) as the 00 00 5 display list store 1400, or may be implemented as individual stores for reasons of speed optimisation. The edge processing module 400 uses an edge record store 500 to hold edge Sinformation which is carried forward from scan-line to scan-line. The level activation module 600 uses a level activation table 700 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 generation module 800 uses a fill data table 900 to hold information required to determine the fill colour of a particular priority at a particular position. The pixel compositing module 1100 uses a pixel compositing stack 1200 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 1400 and the other stores 1600 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 1500. 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, with upstream processing suspended until the downstream module completes the processing of the message.

731955.doc On each scanline, the edges of objects which intersect that scanline are held in Sorder of increasing coordinate of intersection with the scanline. For each scanline the ND display list commands which describe the location and attributes of object edges are read by the Edge Processing Module 400. There are two possible sources of edge data; new 00 00 5 edges from the display list for objects that first appear on the current scanline, and edges which have continued from the previous scanline. Edges that have propagated from the Sprevious scanline are stored in a buffer called the Input Buffer in the Edge Record Store 500, and are merged dynamically in ascending x-coordinate order with new edges from the display list. If an edge continues to the next scanline, its x-coordinate is updated and a record is created in another buffer in the Edge Record Store called the Output Buffer. At the end of the scanline after all edges have been processed the system swaps the Input Buffer and Output Buffer and starts processing edge records for the next scanline, reading edge records from the display list and the Input Buffer (which contains edges propagated from the previous scanline). Edges that do not propagate to the next scanline are called Terminating Edges. They are considered only for the current scanline, and are not updated and copied to the Output Buffer.

When the Edge Processing Module 400 encounters an edge on the current scanline it passes information, in the form of edge crossing commands or edge records, to the following module, the Level Activation Module 600, which controls an array of render state variables stored in the Level Activation Table 700. These state variables may contain such attributes as: Object Active, Fill count, Need Below, Priority, and are updated whenever the system determines that the edge of an object has been crossed.

Between each pair of edges considered, the colour data for each pixel which lies between the first edge and the next edge is generated by using a priority encoder on the 731955.doc active flags to determine which priority is topmost, and using the colour associated with Sthat priority for the pixels of the span between the two edges.

The pixel-sequential rendering apparatus described with reference to Fig. 3 can be modified such that it is able to directly render pixel data in block order without the 00 00 5 requirement for intermediate storage, external to the system, as discussed above. In such a modified system, for the output image to be divided into blocks, the rendering process will become discontinuous at block boundaries across the scanline. At these discontinuities state variables (fill counts, etc) need to be stored and then later restored so that rendering can proceed to the next block.

Unfortunately, the collection of state variables in this method is often very large and the bandwidth required for their storage may cancel any benefit of rendering blocks within the system compared with the solutions discussed in the background art. However, the arrangements described below allow pixel data to be rendered efficiently in block order.

In a first arrangement, block order rendering is achieved by reordering edge crossing commands. Separate Input Buffers and Output Buffers are allocated in rendering stores 30 for each line in the block. Thus, for 8x8 pixel blocks there will be eight Input Buffers 2000 and eight Output Buffers 1950, as shown in Fig. 4.

The rendering process of the first arrangement proceeds in two phases, as shown in Fig. 4. For the case of a block size of 8 x 8 pixels, the operations are: Phase 1: Edge Tracking of 8 Scanlines The Edge Processing Module 400 reads eight lines' worth of edge information 1850 from the display list 1800, tracking in step 1900 all the edges as they propagate from the first line to the eighth line. The Edge Processing Module 400 then writes edge crossing commands for each line to the eight 731955.doc Output Buffers 1950. The Output Buffers for the first seven lines only contain

U

Lightweight Edge Records. A Lightweight Edge Record contains the following O information: X-Coordinate of edge; 00 00 5 Level(s) affected by the edge; "Edge Type, which contains information such as: ,In o The way edges are represented segments, bitmap font); o How edge(s) are generated from the edge record (e.g.

Postscript edge types will generate a start and end edge); o Which pixel the edge crossing affects pixelisation and rounding rules); and o How the edge crossing interacts with levels (e.g.

incrementing fill counter, decrementing override counter, etc).

A Full Edge Record contains the following information in addition to the information contained in the Lightweight Edge Record: Y Offset, which determines the starting point of an edge with respectto the current scanline; and Segment Data, a list of subsequent segments that may correspond to vectors described by a sequence of dx/dy pairs of data and/or edges of bitmaps.

Thus the Output Buffers for the first 7 lines do not contain segment data that must be tracked to the subsequent scanline, i.e. the edge records contained therein are treated as Terminating edges. The buffer for the last line contains Full Edge Records, i.e. the last line's buffer additionally contains data for segments to be tracked to the next line the 731955.doc first line in the subsequent set of eight lines), and so will be larger than the Output Buffers

U

for the first seven scanlines.

IIn Fig. 4, the arrows and numbers indicate the direction in which rendering proceeds during Phase 2 for 8 x 8 pixel blocks. Fig. 4 shows 128 pixels in two adjacent 8 00 00 5 x 8 blocks. The numbers 1 128 illustrate the sequence of rendering. Within the first block 2075, pixels 1 8 lie along a first scanline, while pixels 1, 16, 17, 32, 33, 48, 49 and 64 lie on adjacent lines in scanline order. The sequence proceeds in serpentine or zigzag order down the first block, as indicated by reference numeral 2150, so that, for example, the pixel in the 8 th column of the first row is followed by the pixel in the 8 th column of the second row. Once the final pixel 64 of the first block has been reached, the sequence proceeds along the dashed path 2200 to the bottom right comer of the second block 2100 and works back up the block 2100 in serpentine order.

Since the rendering process in Phase 2 proceeds in a serpentine order 2150 edge records in even numbered Output Buffers must be sorted upon writing during Phase 1 in reverse x order within the span of each block. For example, on line 1, the render direction is forward increasing x) so edge records that fall within the pixel 1 and pixel 8 are sorted in increasing x order. On line 2, the render direction is reversed decreasing x) so edge records that fall within the first pixel and the eighth pixel are sorted in decreasing x order. Note also that edge records in even numbered output buffers are stored with the opposite sense to that output by the Edge Module 400 during Phase 1. That is, an edge found to activate a certain level during Phase 1 on an even-numbered scanline will be stored with its attributes set to deactivate that level in the corresponding output buffer.

The result of Phase 1 as shown in Fig. 5 is a set of 8 Edge Buffers 4025 to 4032 (pointed to by pointers 4011 to 4018) that contain edge records 4021, 4022, 4023 for eight 731955.doc -18- O contiguous lines, already sorted by X-coordinate according to the serpentine block render U directions shown in Fig. 4. Fig. 5 shows an illustrative example in which two adjacent 8 x I8 blocks are divided into ten distinct areas by object edges. Thus, for example, scanline 1 has object edges before the first, fourth, sixth, ninth, and fourteenth pixels. The edge 00 00 5 buffer 4025 for the first scanline has edge records corresponding to the edges at xcoordinates 1, 4, and 6 in the first block, and an edge record corresponding to the edge at x-coordinate 14 in the second block. (The edge record with x-coordinate 9 is shown with dotted shading because it is of special character, to be described later). Note that the xcoordinate of an edge indicates that a change in activity state occurs immediately before the indicated pixel in the rendering order. The order of edge records in the edge buffers is determined by the serpentine rendering order. For example, the edge buffer 4032 for the eighth scanline has edge records corresponding to the edges at x-coordinate 3 in the first block and edge records corresponding to the edges at x-coordinates 13 and 10 in the second block, in that order because of the decreasing-x-coordinate rendering order at that scanline.

To account for changes of activity state across the "reversal points" of the serpentine path between pixels labelled 8 and 9 in Fig. special edge records representing "horizontal" edges need to be inserted into the edge buffers. These special edge records are shown filled in with dots in Fig. 5. For example, the special edge record 4035 in edge buffer 4026 for the second scanline has x-coordinate 8 and represents the change in object activity state between pixels 8 and 9 in the serpentine rendering order.

Likewise, the edge record 4036 in edge buffer 4029 for the fifth scanline has x-coordinate 1 and represents the change in object activity state between pixels 32 and 33 in the serpentine rendering order. Special edge records are also present on scanlines 1, 3, 4, 7, 731955.doc and 8 in the example of Fig. 5. Note that the special edge record in buffer 4025 for the U first scanline, with x-coordinate 9, does not represent the vertical edge between pixels IND with x-coordinates 8 and 9 on the first scanline, but rather the change in state between pixels 120 and 121 in the serpentine rendering order. Likewise, the vertical edge between 00 00 5 pixels with x-coordinates 8 and 9 on scanline 6 has no corresponding edge record in any buffer, because it does not represent a change in state along the serpentine rendering path.

SPhase 2: Block Pixel Order Rendering (step 2050): The set of Output Buffers written in Phase 1 are now used as the input 2000 to the block rendering method, and another set of buffers are then used as Output Buffers 1950 for Phase 1 of the next eight scanlines (these two phases, i.e. Phase 2 for the first eight scanlines and Phase 1 for the next eight scanlines, can now operate in parallel, and re-use the same two sets of buffers which are swapped each time both phases complete).

For each line in the block starting at line 1 the edge records are read by the Edge Module 400 from the corresponding Input Buffer 2000 and the X coordinate of each consecutive edge is tested to see if it falls within in the x-direction span of the current block 1 to 8 for the first block 2075 of Fig. 4, or 9 to 16 for the second block 2100).

If it does an edge crossing message is emitted to downstream modules, in this case the Level Activation Module 600, thus triggering the render pipeline 1500 to render pixels between the present edge and the previous edge. If the x-coordinate of an edge falls outside the span of the current block, the edge record remains for the next block and rendering proceeds to the next line.

The Level Activation Module 600 also needs to know the direction of the render, since the interpretation of which pixel the new levels become active on depends on the direction of the render. This direction can be determined by the current line number. Odd 731955.doc pixels are rendered in the increasing-X direction, even lines are rendered in the Sdecreasing-X direction. This process continues for each of the eight lines until the last _D pixel in the first block is reached. Note that the ordering of the Edge Crossing Commands in the Input Buffer 2000 effectively orders the rendering in the serpentine order shown in 00 00 5 Fig. 4.

The operation of the Level Activation Module 600 also changes to handle the case of the last line of the block. When the Edge Processing Module 400 processes the last edge record for line 8 the corresponding pixel location is 64, at the bottom-left of the block. The next edge record to be processed corresponds to pixel 65, at the bottom right of the next block 2100. The render state variables stored in the Level Activation Table 700 after pixel 64 need to be adjusted to cope with this discontinuity. As the system processes edge records from the first block from pixel 57 to pixel 64 the Level Activation Module 600 must record the changes made to the render state stored in the Level Activation Table 700 during this process in an Undo Buffer. These changes are then reversed to return the Level Activation Table 700 to the state as it was before pixel 57.

During this undo process the Level Activation Module 600 only adjusts the render state variables in the Level Activation Table 700, it does not generate 'pixelatlevel' instructions for downstream modules 800, 1100.

The Edge Processing Module 400 now starts to process edge records for the "first line" of the second block. Due to the serpentine render path, the first line to be processed in the second block is line 8 (see Fig. Edge records in this line are sorted in the reverse X direction, so pixels will start to be output from the bottom right hand side of the block.

To ensure that the Level Activation Table 700 is in the correct state to start rendering again from this point (pixel 65 in Fig. the Edge Processing Module 400 needs to pre- 731955.doc fetch edge records for the span of line 8 to a temporary buffer, and read them in reverse

U

Sorder compared to the render direction in the direction of pixel 72 to 65 in Fig. 4).

IND The Edge Processing Module 400 passes edge crossing commands read in reverse order from the temporary buffer to the Level Activation Module 600, which updates the render 00 00 5 state in the Level Activation Table 700 accordingly. Once again during this process the LAM 600 will not generate pixelatlevel instructions for downstream modules 800, 1100.

After this process the render path is at pixel 65, and the Level Activation Table 700 is in the correct state for this point, so the render process can start again. First the edge records for line 8 are read from the temporary buffer in the order pixel 65 to 72, and edge crossing commands are sent to the Level Activation Module 700 which generates corresponding pixel_at_level commands for downstream modules 800 and 1100, thus triggering rendering of pixels. Then the Edge Processing Module 400 reads edge records from the Input Buffers for the other lines in the block from Line 7 down to Line 1.

When Line 1 of the second block has been processed, the same render sequence is repeated for the next two blocks on the same scanlines, and so on until the row of blocks is completed.

Other modules in the system also need to be aware of the current pixel number in the rendering path to control their operation as follows: The Fill Colour Generation Module (CGM) 800 contains an X-position Counter and a Y-position counter that enable it to correctly calculate pixel colours during blends and bitmap fills. The CGM 800 needs to know which line and which block is currently being processed so that it can correctly modify the X and Y count during block rendering.

731955.doc Due to the serpentine render path the pixels generated by the Pixel Composting SModule 1100 are not in the correct order for output. To correct for this the Pixel Output IModule 1300 must buffer each block of pixels and correct the blocks as follows; 1. Transpose rows 2, 4, 6, 8 in each block in the X direction.

00 00 5 2. Transpose every second block in the Y direction.

8 A second arrangement is now described with reference to Fig. 6 and those following. The second arrangement is described with reference to the illustrative example of Fig. 7, which shows 8 scanlines, of each of which the first 8 pixels form an 8 x 8 block to be rendered.

Fig. 6 shows a portion of scanline 3000, which corresponds to the 6 th scanline of the example of Fig. 7. For each scanline 3000, as new edge crossings 3012 3014 are considered, the Level Activation Module 600 is responsible for determining a list of levels that are contributing to the final output colour between the current edge and the previous edge. The list is generated by using a priority encoder on the levels' active flags to determine which priorities are topmost. The span between the two edges is defined to be a region. The Level Activation Module 600 generates region commands 3015 3017 that are made up of the list of contributing levels 3018, the length of the span 3019 and various region attributes. Note that a region command does not necessarily represent a span of constant colour. Rather, it represents a span of objects that are consistently contributing to the output image. In the example, region command 3015 has a span of three pixels and relates to the region between edges 3012 and 3013, having a list of contributing levels 3018. Region command 3016 spans 5 pixels between edges 3013 and 3014. Region command 3017 spans 3 pixels after crossing 3014.

731955.doc In the second arrangement, block order rendering is achieved by reordering region Scommands. To reorder, Level Activation Module 600 maintains a region buffer 3133 IND (seen, for example in Fig. containing separate region line buffers for each scanline. In one arrangement, 8x8 blocks would require eight region line buffers 3004 3011. The 00 00 5 rendering process proceeds in two phases, and for the example of a block size of 8x8 pixels, the operations are: SPhase 1. Region generation and buffering The Level Activation Module 600 generates region commands for eight lines worth of edge crossing commands as described above. For each line, the region commands are stored sequentially in the associating region line buffer. For example, in Fig. 6, region commands 3015 3017 are generated in raster order on the sixth scanline 3000 and then stored sequentially in the order 3001, 3002, 3003 in the associated sixth line buffer 3009.

Phase 2. Region reordering For each of the eight region line buffers 3004 3011 in Fig. 7, the LAM 600 maintains a corresponding pointer 3111 3118 that points to the next region command to read out in the line buffer. The LAM 600 also maintains an Xcounter 3101 3108 for each of the eight lines. The X-counters keep track of X positions along a given scanline for which region commands have been output. Before region reordering begins, LAM 600 initialises all pointers 3111 3118 to point to the first region command in each line buffer 3004 3011 and sets all X-counters 3101 3108 to zero.

Processing starts with line 1 of the first block. The processing is illustrated in Figs. 8A to 8C, which show a sequence of operations. Starting with the first region line buffer 3004, the region command 3121 pointed to by the buffer's pointer 3111 is read.

The region's span length (in this case three pixels) is added to the line's X-counter 3101.

As the result of the addition is less than the X location of the next block boundary 3212 731955.doc

O

(in this case after pixel the region command 3121 is output as indicated at reference Snumeral 3201, the X-counter 3101 is incremented by the region's span length, as indicated ND at reference numeral 3200, and the line buffer pointer 3111 moved to point to the next region command 3122, as indicated at reference numeral 3203.

00 00 5 Then, as seen in Fig. 8B, the second region command 3122 is read from the line buffer 3004 and the span length of two pixels is added to the line's updated X-counter S3101. As the result of this addition is also less than the X location of the next block boundary, the region command 3122 is output, as indicated at reference numeral 3205, the X-counter 3101 is incremented by the region's span length, as indicated at reference numeral 3204 and the buffer pointer 3111 is incremented to point to the next region command 3123, as indicated at reference numeral 3207.

This process of reading out the next region command continues until the addition of the span length to the X-counter 3101 is equal to or greater than the X-location of the next block boundary 3212. In the situation shown in Fig. 8C, the region corresponding to region command 3123 ends at the block boundary, and thus adding the span length to the X-counter 3101 gives a result of 8. The region command 3123 is output, as indicated at reference numeral 3209, the X-counter 3101 is incremented by the region's span length, as indicated at reference numeral 3208 (after which the X-counter equals the X-location of the block boundary 3212), and the pointer 3111 is moved to point to the next region command 3211. Because the region command 3211 relates to the following block on line 1, processing moves to the next line of the current block. Thus, the next region command that is read is from the location 3213 pointed to by the line buffer pointer 3112 of the next line buffer 3005. Starting with the first region command from the next line buffer 3005, the process continues.

731955.doc

M

O On line one of the example, the region edge coincides with the block boundary.

U Figs. 9A and 9B illustrate the method used where a region flows over a block boundary ND into an adjacent block, for instance in lines 2, 3, 4, 5, 7, and 8 of the example of Fig. 7.

Referring to Fig. 9A, the span 3301 of a region on the fifth line of the block 00 00 5 traverses the block boundary 3307. The region command specifies the full span of seven F pixels. In this situation, the portion 3305 of the region 3301 that lies within the current C)block is output. The output region command 3304 specifies a span of three pixels, corresponding to the portion 3305, and the X-counter 3105 is incremented by the span length of the portion 3305 (taking X-counter 3105 up to the X location of the next block boundary 3307). Reference numeral 3300 indicates the value of the X-counter before the current addition, and reference numeral 3303 indicates the value of the X-counter after the addition.

The line buffer pointer 3115, however, is not moved, and the region command 3306 still pointed to by pointer 3115 (corresponding to the remaining portion 3308 of region 3301) has its span length 3309 decremented by the length of the span that was output in order to reflect the region's truncated state. Thus, the span length stored in the region command 3306 is now four pixels. Processing of the current block then continues on line 6. The line buffer 3008 has been left in a state that enables correct processing when the adjacent block to the right of the current block is subsequently rendered.

Region or block commands are output from the line buffers, line by line, until the block boundary of the last line of the block is reached, as indicated by reference numeral 3402 in Fig. 10A. At this point, the last region command 3401 for the first block is output from line buffer 3011 and all X-counters 3101-3108, as indicated by reference numeral 3400 are equal to the X-location of the next block boundary (in this case Once a full 731955.doc block has been output, the reordering process will continue starting with the next region Scommand 3403 pointed to by line pointer 3111 in the first line buffer 3004.

SReferring to Fig. 10B, when the pointer 3407 for the last line buffer 3011 points to the end 3404 of the line buffer 3011, it signals that the last region command 3405 has 00 00 5 been output for all 8 buffered lines. This also implies that all X-counters 3101 3108 will be set to the total scanline span as indicated at reference numeral 3406. This completes phase 2.

Phases 1 and 2 are continually repeated, 8 scanlines at a time, until the Level Activator Module 600 receives no more edge crossing messages.

This second arrangement described includes a general method of buffering and reordering the generated regions to achieve the desired block order of output pixels.

Optimizations to this general approach are possible which further reduce the amount of memory required.

In the first of these optimizations, compression is used to reduce the memory required. Region commands were previously defined to comprise a list of contributing levels, the length of the span and some region attributes. It is useful to further divide these region commands into two parts, the region contributing level list (RCLL) and the region span and attributes (RSA). Each region will always have an associated RSA, but depending on a region's attributes it may not always have a RCLL. The RCLL and RSA parts of region commands are compressed separately and are written out to separate locations in memory. This separation allows different compression schemes to be employed to better suit the nature of the two different data streams. For example, when devising a RCLL compression scheme the locality of level numbers may be exploited by entropy coding the differences between subsequent level lists. Similarly, when 731955.doc

O

compressing RSAs, the static nature of certain attributes may be easily exploited. This Scould be done by encoding unchanged RSA Attributes using a single "unchanged" bit, IND while encoding changed RSAs using a 'changed' bit, followed by the new attributes.

Fig. 11 shows a design for a Level Activation Module 600 which uses this 00 00 5 optimization. A line index table 3506 is used to track the region data in the region buffer 3503, which replaces the structure 3133 of Fig. 7. An entry in the Line index table 3506 is maintained for each line of region commands stored in the region buffer 3503. An ,I entry in this table 3506 consists of: pointers to the RCLL and RSA compressed data 3504, 3505 in region buffer 3503; compression state for the two compression methods; and current Region X Offset. When a line is written to memory by Region Write module 3502 this information is written to the Line Index Table 3506. Once sufficient line entries are available in the line index table 3506 then block-order region reading block 3501 may commence reading for this row of blocks. The number of line entries required is equal to the block height in scanlines. Data is read to reconstruct the regions up to the end of the first block in a row. The table entry is then updated to point to the start of the line in the second block of this row. This is repeated each time data for a given line is required until all of the line has been read.

Once a line of data has been completely read from the region buffer 3503, then its associated line index table entry may be marked as invalid. This entry position may then be reused by the write block 3502, as is convenient, for a subsequent line. A further benefit of this optimization now becomes apparent: The number of entries in the index table may then be used to trade off this system's throughput with its peak memory requirement. If a large number of entries are available, then the read block 3501 and write block 3502 may proceed concurrently, as once the initial row of lines has been written 731955.doc -28there will be sufficient table entries for reading and writing, at the expense of a large U number of line buffers in the region buffer 3503. Conversely if a minimal number of

C

ND entries (the same as the block line height) is used, then the read and write blocks will operate sequentially with the benefit of fewer line buffers being required.

00 00 5 A further optimization eliminates the need for separate line buffers in region buffer 3503, in favour of an approach which uses dynamic memory allocation. In an Soptimized system which supports memory block allocation and freeing, separate line buffers are not required. A more efficient approach may be taken where only two linked lists are maintained, one list for compressed RCLLs (as shown by block 3505) and another list for compressed RSAs (as shown by block 3504). New data blocks are allocated and added into the lists as required. Once all of the RCLL or RSA information stored in a given block has been read, then the memory assigned to this block may be freed. Extra information is stored along with the compressed RSAs and RCLLs in these lists to support this process. This optimization is particularly useful as the amount of data required to buffer a single scan line may vary quite significantly, and it is difficult to determine an upper limit on the size of this information. This optimization allows a more efficient dynamic approach to memory allocation.

Within the rendering system of Fig. 1, a "fallback" scenario occurs when resources within the rendering apparatus 20 are exhausted. A typical example of this occurs when the number of levels present within the display list exceeds a predetermined limit. In a "fallback" scenario, the display list which will exhaust the resources is split into a series of display lists representing successive "layers" in ascending priority order. The levels in 731955.doc -29-

O

each layer are rendered and stored for later use as a background image for the succeeding Slayer.

IND When performing a layered render, pixels are produced at the end of the pipeline 1500 by the Pixel Output Module 1300 and consumed by an external compression module 00 00 5 (not shown), typically JPEG based, which compresses the rendered layer. The rendering apparatus 20 further includes a decompressor module (not shown) capable of decompressing the compressed background layer.

Typically, the background layer is a full resolution image. So, for an A4 page at 300 dpi, which measures 210 mm x 297 mm, the total memory needed to hold this background layer as a bitmap in memory is: Total memory 210/25.4 x 300 x 297/25.4 x 300 x 3 channels x 8 bits pixel 200 Mbytes A typical compression ratio for the JPEG compression of this image may be 10:1, meaning the JPEG compressed background image typically occupies 20 Mbytes.

Typically, when a new layer is received, an instruction is passed between the Fill Colour Generation Module 800 and the decompressor module whereby the Fill Colour Generation Module 800 requests the execution of a decompression task. Upon receiving the decompression task, the decompressor module fetches the compressed data via DMA, passes the data through a hardware decompressor core, and then writes the decompressed data to memory. Upon completion, the decompressor module then signals to the Fill Colour Generation Module 800 that the decompression is complete. At this point, the Fill Colour Generation Module 800 can fetch the background layer for the entire page.

In this event, total reads 20Mbytes for compressed data by DC 200Mbytes for decompressed data by CG.

731955.doc Total writes 200 Mbytes for write back of decompressed data by DC.

U Total memory accesses for background layer 420 Mbytes.

In this implementation, because a scanline render is occurring, system memory 3 must be used as a background buffer since it is impractical to have a dedicated 00 00 5 background buffer of several hundred megabytes. This puts a large burden, both in required memory and access bandwidth, on the system memory 3.

SBlock-order rendering by the renderer 20 as described above presents an N opportunity to drastically reduce the memory needed for fallback layer rendering and also the bandwidth on the system memory bus. Rendered pixels from a layer are presented to a JPEG compressor module in block order, preferably at a block size expected by the compressor module (a typical Minimum Coding Unit, or MCU, being 8 by 8 pixels). To render the next layer, background pixels are read back from the decompressor by the Fill Colour Generation Module 800 in block order in synchronism with the progress of rendering the corresponding block of the next layer. Each background image pixel is therefore available for compositing with the next layer by the Pixel Compositing Module 1100 precisely when it is needed, with no buffering required.

If the renderer 20 utilises block sizes larger than the JPEG compression decompression block size, a buffer is needed on both decompression and compression to reorder the data. For example, 32 x 32 block rendering requires a 16 MCU buffer, i.e 16 x 6 4 x 3 x 8 25 kbits.

By synchronising the decompressor and the Fill Colour Generation Module 800, access bandwidth is reduced to approximately 1/20th of that required for scanline order rendering. Also, the memory requirement is approximately 1/100th of that required for scanline order rendering.

731955.doc -31- The present specification discloses apparatus for performing the operations of the

U

Smethods. Such apparatus may be specially constructed for the required purposes, or may IND comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented 00 00 5 herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate.

In addition, the present invention also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the preferred method described herein are to be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. Furthermore one or more of the steps of the computer program may be performed in parallel rather than sequentially.

Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The computer readable medium may also include a website serving recorded information. Furthermore, the software may be received and loaded from computer readable media using a wireless medium such as the GSM mobile telephone system. The 731955.doc O computer program when loaded and executed on a computer effectively results in an apparatus that implements the steps of the preferred method.

IND 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 00 00 5 have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

O Industrial Applicability It is apparent from the above that the disclosed methods are applicable to the image processing industries.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiment(s) being illustrative and not restrictive.

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

731955.doc

Claims (9)

1. A method of rendering one or more graphical objects within a block of a pixel- 00 5 based image comprising a plurality of scanlines, each object comprising edge data and 00 a fill, said method comprising the steps of: In, traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order.

2. A method according to claim 1, wherein said buffering step buffers edge crossing commands corresponding to object edges, the commands comprising an identifier of one or more of the objects and a scanline x-coordinate, the command indicating that the attributes of the or each identified object are to be updated at a pixel indicated by said x-coordinate on said scanline.

3. A method according to claim 2 wherein said buffering step comprises, for each alternate scanline in said block, buffering said edge crossing commands in the opposite order to that of said traversing of scanlines within said block.

731955.doc O

4. A method according to any one of the preceding claims wherein said determining, U computing and outputting steps process the pixels within the block in a serpentine IND fashion wherein alternate scanlines in the block are processed in opposite directions. 00 00 5

5. A method according to claim 4 comprising the further step of: changing an order of pixels output by said outputting step such that a sequence of pixels for the block follows a predefined render order.

6. A method according to claim 1, wherein said buffering step buffers region commands comprising a list of objects and a length of a span of pixels, the region command indicating that each object in the list contributes colour to pixels belonging to the span.

7. A method according to claim 6 comprising the further step, if the span of a currently considered region command extends beyond a boundary of the block, of: buffering the currently considered region command for further processing, the span length of the buffered region command being reduced by a number of pixels that lie within the block.

8. A method according to any one of the preceding claims wherein the image is divided into a plurality of said blocks and the image is rendered block by block. 731955.doc

9. A method of rendering one or more graphical objects within a block of a pixel- U based image comprising a plurality of scanlines, each object defined by object edges IDand fill data, said method comprising the steps of: traversing scanlines that overlap the block; 00 00 5 identifying regions on the traversed scanlines that lie between adjacent object edges; Sstoring region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; determining stored region commands relating to pixels within the block; and computing a colour of pixels within the block using the determined region commands and related fill data. A method according to claim 9 wherein the region commands are stored in a buffer and said determining step removes a currently-considered region command from consideration within the buffer if the span of the currently-considered region command lies wholly within the block. 11. A method according to claim 9 wherein the span of a currently considered region command lies partially within the block and said method comprises the further step of: reducing the span length of the currently-considered region command by a number of pixels that lie within the block. 731955.doc 12. A method according to any one of claims 9 to 11 wherein said storing step 1comprises the substeps of: IND separating the region commands into a first part comprising a list of active objects and a second part comprising the span length; 00 00 5 compressing the first part and the second part; and buffering the compressed first and second parts. 13. A method according to claim 12 wherein said compressing substep uses different compression methods for the first part and the second part. 14. An apparatus for rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said apparatus comprising: means for traversing scanlines that overlap the block; means for buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; means for determining buffered commands relating to the colour of pixels within the block; means for computing the colour of pixels within the block using the determined commands and the fills; and means for outputting the computed colour of the pixels in the block in scanline order. 731955.doc An apparatus for rendering one or more graphical objects within a block of a Spixel-based image comprising a plurality of scanlines, each object defined by object IDedges and fill data, said apparatus comprising: means for traversing scanlines that overlap the block; 00 00 5 means for identifying regions on the traversed scanlines that lie between adjacent object edges; Smeans for storing region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; means for determining stored region commands relating to pixels within the block; and means for computing a colour of pixels within the block using the determined region commands and related fill data. 16. A system for rendering one or more graphical objects within a block of a pixel- based image comprising a plurality of scanlines, said system comprising: memory storing object information, each object comprising edge data and a fill, said memory further buffering commands relating to the colour of pixels to be rendered along the scanlines; and a processor in communication with said memory and configured to implement the steps of: traversing scanlines that overlap the block; buffering commands in said memory relating to the colour of pixels to be rendered along the traversed scanlines, using the edge data; 731955.doc determining buffered commands relating to the colour of pixels within the Sblock; IN computing the colour of pixels within the block using the determined commands and the fills; and 00 00 5 outputting the computed colour of the pixels in the block in scanline order. 17. 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 of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said method comprising the steps of: traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block; computing the colour of pixels within the block using the determined commands and the fills; and outputting the computed colour of the pixels in the block in scanline order. 18. 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 of 731955.doc rendering one or more graphical objects within a block of a pixel-based image Scomprising a plurality of scanlines, each object defined by object edges and fill data, IND said method comprising the steps of: traversing scanlines that overlap the block; 00 00 5 identifying regions on the traversed scanlines that lie between adjacent object edges; Sstoring region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; determining stored region commands relating to pixels within the block; and computing a colour of pixels within the block using the determined region commands and related fill data. 19. A computer program comprising machine-readable program code for controlling the operation of a data processing apparatus on which the program code executes to perform a method of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object comprising edge data and a fill, said method comprising the steps of traversing scanlines that overlap the block; buffering commands relating to the colour of pixels to be rendered along said traversed scanlines, using said edge data; determining buffered commands relating to the colour of pixels within the block, 731955.doc O computing the colour of pixels within the block using the determined Scommands and the fills; and IND outputting the computed colour of the pixels in the block in scanline order. 00 00 5 20. A computer program comprising machine-readable program code for "t controlling the operation of a data processing apparatus on which the program code 0 executes to perform a method of rendering one or more graphical objects within a block of a pixel-based image comprising a plurality of scanlines, each object defined by object edges and fill data, said method comprising the steps of: traversing scanlines that overlap the block; identifying regions on the traversed scanlines that lie between adjacent object edges; storing region commands corresponding to the identified regions, the region commands identifying objects that are active in the corresponding region and a span of pixels lying within the region; determining stored region commands relating to pixels within the block; and computing a colour of pixels within the block using the determined region commands and related fill data. 21. A method of rendering one or more graphical objects within a block of a pixel- based image substantially as described herein with reference to any one of the embodiments as illustrated in the accompanying drawings. 731955.doc -41- S22. An apparatus for rendering one or more graphical objects within a block of a Spixel-based image substantially as described herein with reference to any one of the IND embodiments as illustrated in the accompanying drawings. 00 00 5 23. A system for rendering one or more graphical objects within a block of a pixel- based image substantially as described herein with reference to any one of the embodiments as illustrated in the accompanying drawings. 24. A computer program product substantially as described herein with reference to any one of the embodiments as illustrated in the accompanying drawings. A computer program substantially as described herein with reference to any one of the embodiments as illustrated in the accompanying drawings. DATED this Sixteenth Day of December 2005 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON&FERGUSON 731955.doc