BACKGROUND OF THE INVENTION
Raster Image Processing (RIP) involves processing an image described in Page Description Language (PDL) and results in the creation of a pixel map of the image.
As shown in Fig. 1, a PDL file 20, i.e., postscript, includes two stages, an interpretation stage, processed by interpretation module 20, and a rendering stage, processed in rendering module 26, for generating the pixel map of the image to image plane 28.
During the interpretation stage, the PDL file 20 is processed and a list of display elements, called a display list 24, is generated. The display elements included in the display list 24 include objects such as trapezoids, run lines and fonts.
The rendering stage has as input the display list 24 generated during the interpretation stage. During the rendering stage, each display element in the display list 24 is processed and pixel values are written to the image plane 28.
In PDLs such as postscript, an object is classified as opaque when, for example, an object A is fully or partially placed on top of another object B. The order of the elements in the display list 24 defines the overlay order of the objects represented. For example, if the first and second objects in the display list 24 overlap, then the second object overlays the first object since it comes later in the display list 24 than the first object.

The conventional method of rendering object in sequential order as defined by the display list 24, however, includes two limitations. First, the conventional approach results in the overwriting of overlapped parts of previously rendered objects. The rendering of the overwritten part is not required and, in most cases, such rendering uses a significant amount of processing time.
Another limitation of the conventional approach of rendering objects from the display list 24 is that task partitioning for parallelization diuing the rendering process is not supported since the final image depends on the overlapping of the objects.
Thus, what is needed is a method and system for determining overlap information of objects in a display list and using this information to prevent redundant rendering of an image and to support parallelization of the rendering process.

SUMMARY OF THE INVENTION
In a first embodiment of the present invention a plurality of objects in a display list are preprocessed to determine overlap information between the objects. The objects are then resized in accordance with the overlap information before rendering the objects to an image plane.
In another aspect of the present invention, the overlap information is used to support parallel processing while rendering the objects to the image plane.

BRIEF DESCRIPTION OF THE DRAWINGS
For a better understanding of the present invention, reference may be made to the accompanying drawings, in which:
Fig. 1 is a block diagram of a prior art image processing system;
Fig. 2 is a block diagram of an image processing system in accordance with the present invoition;
Fig. 3 is a block diagram of an exemplary hardware configuration for implementing the present invention;
Fig. 4 illustrates an exemplary overlay graph generated in accordance with the present invention;
Fig. 5 shows a block diagram of one embodiment of the present invention;
Fig. 6 depicts a portion of the data structures used in the present invention;
Fig. 7 depicts a node data structure used in the present invention;
Fig. 8 is a flow diagram illustrating the operation of a build graph module used in the present invention;
Fig. 9 is a flow diagram illustrating the operation of an overlay module used in the present invention;
Figs. lOA-B show flow diagrams illustrating the operation of a dip polygon module used in the present invention;
Fig. 11 illustrates the operation of a merge module used in the present

invention;
Fig. 12 depicts a flow diagram illustrating the operation of a resize object module used in the present invention;
Fig. 13 is a flow diagram showing the operation of a partition graph module used in the present invention;
Fig. 14 illustrates a flow diagram showing the operation of a first embodiment of a parallel partition module used in the present invention;
Fig. 15 shows an exemplary graph illustrating the operation of the first embodiment of the parallel partitioning module; and
Fig. 16 is a flow diagram illustrating a second embodiment of the parallel partitioning module.

DETAILED DESCRIPTION OF THE INVENTION
The present invention, as shown in Fig. 2, includes a method and system for generating and using overlap information in the form or an overlay graph 32 in rendering an image comprised of a plurality of overlapping objects to an image plane 28. A preprocessing module 30 generates the overlay graph 32 in accordance with overlapping of a plurality of display elements in a display list 24. The preprocessing module 30 further partitions the overlay graph 32 into sets, each of which is given an associated set number. Each set of display elements from the overlay graph 32 can then be rendered by a rendering module 26 to image plane 28 in accordance with the associated set number. A plurahty of rendering modules 26 can be executed simultaneously to render each set in parallel.
As shown in Fig. 3, an exemplary implementation of the present invention includes a general purpose digital signal processor (DSP) 44, such as the TMS320 family of DSPs manufactured by the assignee, Texas Instruments Incorporated, which includes a processor 42 and a memory 40. The preprocessing module 30 executes on the processor 42 to generate from the display list 24 the overlay graph 32. Both the display list 24 and the overlay graph 32 are stored in the memory 40.
It is further contemplated that the present invention could be implemented on a general purpose digital computer. It is also contemplated that, to support parallel processing, as discussed hereinbelow, a plurality of

DSPs 44 can be used or a single DSP which includes multiple processors.
Pig. 4 shows an exemplary image 50 comprised of four overlapping display objects A 52, B 54, C 56 and D 58. In accordance with the present invention, an exemplary overlay graph 60 is generated in which node D 68 is a child or descendant of node B 64 and node C 66 since display object D 58 overlaps both display object B 54 and display object C 56. Similarly, node B 64 and node C 66 are shown in the exemplary overlay graph 60 as children or descendants of node A 62 since display object B 54 and display object C 56 both overlay display object A 52. Furthermore, since display object A 52 does not overlay any other object in the exemplary image 50, node A 62 is referred to as a root object in exemplary overlay graph 60.
As shown in Fig. 5, the preprocessing module 30 of the present invention includes a controller module 70 which calls a build graph module 72, a clip polygon module 78, a resize object module 82 and a partition graph module 86. The build graph module 72 in turn calls an overlay module 74 which calls an overlap module 76. The build graph module 72, the overlay module 74 and the overlap module 76 build the overlay graph 32 in accordance with the overlapping of the objects in the display list 24.
The clip polygon module 78 calls a merge module 80. The dip polygon module 78 and the merge module 80 compute clipping polygons for each of the nodes in the overlay graph 32. The clipping polygon for a node is build in accordance with the size of descendant nodes as defined in the overlay graph

32.
The resize object module 82 also calls the overlap module 76 and resizes each node in the overlay graph 32 in accordance with the clipping polygon defined by the dip polygon module 78.
The partition graph module 86 calls the parallel partition module 88 and partitions the display elements, as represented by nodes in the overlay graph 32, into one or more sets depending upon the number of descendant nodes. The operation of each of the modules shown in Fig. 5 is discussed in more detail hereinbelow.^
Figs. 6 and 7 show data structures used in the present invention. The data structures include a Ust of roots 92, a polygon list 94 and a display Hst 98, each of which is implemented as a doubly linked list or as an array. A not_root flag 98 and a done flag 100, each of which are Boolean valued variables, are also used.
Fig. 7 illustrates the structure of a node object 102, a pluraUty of which comprise the overlay graph 32. Each node object 102 includes a processed flag 104, a result flag 106 and a sequential gate flag 116, each of which are also Booleem valued. A parent field 108 holds the list of addresses or identifiers of parents, if applicable, of the node object 102. A child list 110, implemented as a doubly-linked Ust of node identifiers or node addresses, lists all children or descendants of the node object 102. A poly list 112, also implemented as a doubly-linked Ust, is a Ust the clipping polygons for the node object 102.

A shape field 114 defines the geometric shape of the display element represented by the node object 102. The shape field 114 is null if the display element is a bit-mapped font or an object filled with bit-mapped mask patterns. A set number field 118 identifies the set number of the node object 102. A path length field 120 for the node object 102 identifies the longest path from the parent/ancestor root object of the node object 102 to the node object 102.
Fig. 8 shows a flow diagram illustrating the operation of the build graph module 72. At block 130, the build graph module 72 initializes the list of roots 90 to null then, If there are display elements in the display Hst 96 as determined at decision block 131, starting at block 132, the build graph module 72 gets the next display element and processes each of the display element in the display Ust 96 in turn as described in more detail hereinbelow.
At block 134, not root flag 78 is initiaHzed to false. The not root flag 78 indicates whether the current display element overlaps with any root or any of its children or descendant nodes in the list of roots 90. If, at decisi(m block 135, the list of roots 90 is not empty or null, then at block 136, a root is retrieved firom the list of roots 90. At block 138, if the current display element overlaps with the current root, as determined by a call to the overlay module 74, discussed in more detail hereinbelow, the not root flag 78 is set to true.
Once the current display element has been compared to all of the roots, if any, in the Ust of roots 90, as shown at decision block 140, the not root flag 78 is checked at decision block 142.

If, at decision block 142, the not root flag 78 is false, indicating that the current display element did not overlap with any of the roots in the list of roots 90, then at block 144, the current display element is deemed to be a root and is added to the list of roots 90. If, at decision block 142, the not root flag 78 is true, indicating that the current display element did overlap with one of the roots in the list of roots 90, then processing continues at block 146 where the markings of the display elements in the display list 96 indicating that the display element has been processed are cleared.
If at decision block 148 all display elements in the display list 96 have been processed, processing in the build graph module 72 terminates. Otherwise, processing continues at block 132 with the next display element in the display list 96.
Fig. 9 shows a flow diagram illustrating the operation of the overlay module 74. In general, the overlay module 74 determines whether a display element in the display list 96 overlaps a root in the list of roots 92 or descendants of the root.
The overlay module 74 initially accepts as input a node object 102 from the Ust of roots 92 and a display element from the display Ust 96. At blodc 150, the done flag 100, is set to false. The done flag 100 is set to true, as discussed hereinbelow, if it is determined that the display element overlaps with any of the descendants of the input node object 102.
At decision block 152, if the input node object 102 is null, processing

terminates and the overlay module 74 returns false as shown at 182. Returning to decision block 152, if the input node object 102 is not null, but, has already been processed, as determined at decision block 154, the value of the result field 106 of the input node object 102 is returned at 156.
If the input node object 102 has not been processed then, each descendant of the input node object 102, if any, as determined at decision block 155, is checked for overlap with the input display element, as shown at blocks 158 and 160 and at decision block 162. As shown at block 160, the overlap module 74 is recursively called for each descendant. The done flag 100 indicates whether an overlap was found.
At decision block 164, if the done flag 100 is true, i.e., the display element overlaps with at least one of the descendants of the input node object 102, then, at block 172 the processed field 104 of the input node object 102 is set to true and at block 174 the result field of the input node object 102 is also set to true. The overlay module 74 then returns a true at 176.
Returning to decision block 164, if the done flag 100 is not true, then, at decision block 166, the overlap module 76 is called to determine if the input display element overlaps with the input node object 102. The overlap module 76 accepts as input two polygons stored in shape field 114, one representing the input display element and the other representing the input node object 102, and determines if the two polygons overlap. If the two polygons overlap, the overlap module 76 returns true, if they do not, the overlap module 76

returns false.
If, at decision block 166, the overlap module 76 returns a true, indicating that the input display element does overlap with the input node object 102, then at block 168, the input node object 102 is set as the parent of the display element and at block 170, the display element is added as a child in the child Ust 110 of the input node object 102 indicating that it is a descendant of the input node object 102. Processing then continues at block 172.
If, at decision block 166, the overlap module 76 returns a false, indicating that thelnput display element does not overlap with the input node object 102, then processing continues at block 178 where the processed field 104 of the input node object 102 is set to true, the result field 106 of the input node object 102 is set to false and, at 182, the overlay module 74 returns a value of false.
After processing by the build graph module 72, the overlay module 74 and the overlap module 76, the overlay graph 32 is defined by the list of roots 92 where eadi root in the list of root 92 defines the root of one of a plurality of non-overlapping objects which make up the image to be rendered to the image plane 26.
Next, the dipping polygon for each of the node objects 102 in the image is computed by the dip polygon module 78. The dipping polygon defines the polygon used to dip the node object 102. Any part of the node object 102 which falls inside the dipping polygon is not rendered. The dipping polygon thus

represents the area in the image plane where descendant objects of the node object 102 are rendered. If the node object 102 was rendered in that area, it would be overwritten by the descendant objects. The clipping polygon for the node object 102 is represented by the poly list 112. Any node object 102 which represents a bit-mapped font or an object filled with a masked pattern requires special handling by the dip polygon module 78. These objects modify only a few selected pixels in the object rendering area. To handle bit-mapped fonts or masked pattern node objects, their shape field 114 is defined as NULL, i.e., they don't dip the'parent object in the overlay graph 32.
The operation of the dip polygon module 78 and the merge module 80, which is used by the dip polygon modtile 78 in defining the dipping polygon, are discussed in detail hereinbelow.
Figs. lOA-B show flowcharts illustrating the operation of the dip polygon module 78. As shown Fig. lOA, the dip polygon module 78 is executed for each root in the list of roots 90 in turn and, as discussed hereinbelow, recursively calls itself to process descendants of the root.
In Fig. lOB, if, at dedsion block 192, the shape fidd 114 of the node object 102 being processed is null, i.e., the node object 102 represents a bit¬mapped font or a masked pattern, processing in the dip polygon module 78 returns a null back to the next highest processing level as shown at 194.
If, at dedsion block 192, the shape fidd 114 of the current node object 102 is not null, processing continues to dedsion block 196 where, if the

processed field 104 has been set to true, processing in the dip polygon module 78 returns the output of the merge module 80 for the poly Ust 112 and the shape field 114 associated with the current node object 102.
Returning to decision block 196, if the current node object 102 has not been processed, processing continues at block 200 where the polygon list 94 is set to null. If the current node object 102 has any descendants, as determined at decision block 201, then the dip polygon module 78, at blocks 202,204 and 206, recursively calls itself and also calls the merge module 80, discussed in more detail hereinbdow, to process each of the descendants of the current node object 102 in turn.
When no more descendants are detected at dedsion block 208, the poly Ust 112 of the current node object 102 is replaced with the polygon list 94 at block 210 and the processed fidd 104 of the current node object 102 is set to true. The dip polygon module 78 then returns to the next highest processing levd the merger of the polygon list 94 and shape 114 as shown at 214.
The merge module 80 accepts as input the polygon Ust 94 and a polygon to test. The merge module 80 then compares the polygon to test with each polygon in the polygon Ust 94. If any two polygons overlap, the merge module 80 joins them to form a new polygon. If the polygon to test does not overlap any polygons in the polygon Ust 94, then it is added to the polygon Ust 94 as a dii^oint polygon.
Fig. 11 shows an example iUustrating the operation of the merge module

80. The polygon list 94 in the example includes polygon 220 and polygon 222. Polygon 224 is to be tested with polygon 220 and polygon 222 to determine if there is any overlap. As shown in Fig. 11, polygon 222 overlaps with both polygon 220 and polygon 222. Thus, the merge module 80 joins polygons 220, 222 and 224 to form the new polygon 226 which is added to the polygon Ust 94.
The resize object module 82 dips each of the display objects using the associated clipping polygons by redefining the shape of the display objects using the associated clipping polygon information. The display objects which represent bit-mapped fonts or masked patterns are handled as special cases and can be clipped by descendant objects but do not contribute to the clipping of parent objects. The operation of the resize object module 82 is illustrated in the flowchart shown in Fig. 12.
Starting at block 230, for each node object 102 in the overlay graph 32, if any, as determined at decision block 228, the resize object module 82 processes each polygon in the poly list 112 associated with each node object 102 as shown at block 232. At decision block 234, the overlap module 76 is called with the current polygon from the poly list 112 and the shape field 114 of the current node object 102 as input parameters. If the overlap module 76 returns a value of true, indicating that the current polygon and the current node object 102 overlap, then the resize object module 82 modifies the shape field 114 of the current node object 102 at block 236 so that the polygon represented by the current node object 102 does not overlap the current polygon from the poly list

112. Thus, each node object 102 is resized in accordance with the polygon shape of each of its descendant objects.
If, at decision block 238 it is determined that all polygons in the poly Ust 112 have been processed, processing continues at block 240 where the display elements are repartitioned into smaller elements if required as a result of the resizing.
At decision block 242, if the node object 102 represents a bit-mapped font or masked pattern, then the sequential gate field 116 is set to true. Then, at decision block 246, if all node objects 102 in the overlay graph 32 have not been processed, control returns to block 230.
After processing by the resize object module 82, the display elements represented in the overlay graph 32 are non-overlapping except for bit-mapped fonts and masked patterns. Thus, conventional rendering using the overlay graph 32 generated in accordance with the present invention, avoids redundant rendering and results in a more efficient rendering process. However, since the elements in the overlay graph 32 are non-overlapping (except for bit¬mapped fonts and masked patterns), the resulting output image does not depend upon the order of their execution. Therefore, the node objects 102 defined by the overlay graph 32 generated in accordance with the present invention, can be rendered in parallel with special processing for bit-mapped fonts and masked patterns.
The parallelization step, performed by the partition graph module 86


Each of these sets are rendered by the rendering module 26 in turn in accordance with their associated set number. The elements in a set, S(n), must be rendered after completion of rendering of the elements in a set S(n-1), where n and n-1 represent the set number.
The controller module 70 initiates parallelization by calling the partition graph module 86. The operation of the partition graph module 86 is shown in the flow diagram in Fig. 13. The partition graph module 86 accepts as input the list of roots 94'and for each root, if any, as determined at decision block 248, retrieves the root at block 250 and at decision block 254, calls the parallel partition module 88 with the root and an initial set number of zero as inputs, as indicated at block 252.
The operation of the parallel partition module 88 is shown in the flow diagrsun in Fig. 14. The parallel partition module 88 implements a modified, depth-first search algorithm and accepts as input an input node object 102 and an input set number. As shown at decision block 260, if the set number field 118 of the input node object 102 is greater than or equal to the input set nimiber, processing in the parallel partition module 88 tenninates.
If, however, the set number field 118 of the input node object 102 is less than the input set number, processing continues at decision block 262. As indicated at decision block 262, if the sequential gate field 116 of the input node object 102 is true, the input set number is incremented by one at block

264 and that set number used to mark the input node object 102 at block 266 and all descendants, if any, as determined at decision block 267, of the input node object 102, as shown at block 268, block 270 and decision bock 272, until another sequential gate element is encountered.
If, for example, there are two sequential gate elements in the graph, the set number is incremented only if one of the sequential gates is a descendant of the other sequential gate. If these two sequential gate elements are on different paths in the graph, then any increase in the set number because of one sequential gatie element will not affect the set number of the other since the sequential gate elements derive their set nimiber from their respective parent nodes.
An exemplary partitioning of nodes in exemplary overlay graph 281 into sets in accordance with the first embodiment of the parallel partition module 88 is shown in Fig. 15. In Fig. 15, node A 280, node B 282, node D 286, node E 288, node G 292, node H 294, node I 296 and node J 298 represent various display objects. Node C 284 and node F 290 represent bit-mapped fonts or masked patterns and, therefore, have their sequential gate field 116 set to true. As shown at block 299, processing the exemplaiy overlay graph 281 results in the set nimiber field 118 of node A 280, node B 282 and node D 286 being set to zero. The set number field 118 of node F 290 is set to one. The set number field 118 of node C 284, node E 288, node G 292, node H 294, node I 296 and node J 298 is also set to one.

In the exemplary overlay graph 281, node C 284 and node F 290 are not descendant or ancestor gates of each other, i.e., they He in different paths from the parent node A 280. Therefore, the final set number for each of the sequential gate nodes is only one. Node C 284 receives as input a set number of zero from node A 280 and node F 290 receives as input a set nimiber of zero from node D 286 (which passed through node B 282 without change). Both node C 284 and node F 290 increment their respectively received set numbers to one but, they do not affect the set number of the other sequential gate node.
The exempli overlay graph 281 thus indicates that node C 284 should be rendered after node A 280 and that node F 290 should be rendered after node A 280, node B 282 and node D 286. However, since node G 284 and node F 290 have the same set number, node C 284 and node F 290 can be rendered in parallel.
If, in the exemplary overlay graph 281, node G 292 were a sequential gate element and node F 290 were not, three sets would be generated. A first set, with set number equal to zero, would include node A 280, node B 282 node D 286 and node F 290 as elements. A second set, with set ntunber equal to one, would include node C 284, node £ 288 and node H 294. A third set, with set number equal to two, would include node G 292, node I 296 and node J 298.
An exemplary application of the first embodiment of the present invention includes the use in designing high performance RIP for production

printing systems where several processors are available for rendering objects in parallel and where real time performance of ripping 50 or more pages per minute is required.
In a second embodiment, it is contemplated that the present invention could be used in low performance RIP, i.e., 10-30 page per minute, by tailoring the parallel partition module 88 as follows.
First, use bounding rectangles of display elements for checking overlapping to build the overlay graph, not the actual polygon.
Second, do not compute the clipping polygon and resize the display object in the preprocessing module.
Third, for parallelization, the display elements are spUt based on paths in the overlay graph 32. The parallel execution must then satisfy the following conditions: (a) children of a node can be rendered in parallel; and (b) for a node to start rendering, all of it's parent node must have completed rendering.
In the second embodiment of the present invention, the paraUel partition module 88, the operation of which is shown in Fig. 16, computes the path length from each root node to each of it's child nodes and uses the path length to determine the rendering order of the nodes. A node object 102 with path length field 120 set to a value of N can be rendered in parallel, but the rendering will start only after the rendering modtde 26 has completed rendering all node objects 102 with a path length field 120 valued N-1 or less. The bit-mapped fonts and masked patterns, indicated by node objects 102 in

which the sequential gate field 116 is set to true, do not require special handling in the second embodiment of the parallel partition module 88.
The second embodiment of the parallel partition module 88, as illustrated in Fig. 16, accepts as input an input node object 102 and an initial path length number. As shown at decision block 300, if the path length field 120 of the input node object 102 is greater than or equal to the initial path length number, processing in the second embodiment of the parallel partition module 88 ends.
If, however, the path length field 120 of the input node object 102 is less than the initial path length number, processing in the parallel partitioning module 88 continues at block 302 where the path length field 120 is set to the initial path length niunber. Descendants, if any, as determined at decision block 303, of the input node object 102 are retrieved at block 304. At block 306, the path length fidds 120 of each of the descendants is updated by a recursive call to the parallel partitioning module 88 until, as determined at decision block 308, all descendants have been processed.
Although the present invention has been described in detail, it should be tmderstood that various changes, substitutions and alterations can be made thereto without departing firom the spirit and scope of the present invention as defined by the appended claims.

WHAT IS CLAIMED IS;
1. A method for rendering an image to an image plane in a memory,
said image comprised of a plurality of overlapping display elements, said
memory coupled to a processor, the method comprising:
(a) providing a display list in said memory, said display list including said overlapping display elements in a predetermined order, said predetermined order defines overlay order of said overlapping display elements;
(b) generating an overlay graph in accordance with said predetermined order wherein said overlay graph defines a first of said display elements as a descendant of a second of said display elements if said first of said display elements overlays said second of said display elements;

(d) defining associated clipping polygons for each of said display elements in accordance with descendants of said each of said display elements to determine overlapped portions of said each of said display elements; and
(e) resizing said each of said display elements in accordance with said overlapped portions defined by said associated clipping polygon to remove said overlapped portions fi-om said each of said display elements thereby generating a resized display elements.
2. The method of Claim 1 wherein
step (b) includes the step of defining said first of said display elements

as a sequential gate element if said first of said display elements is a bit¬mapped font or masked pattern; and
step (d) includes the step of defining associated clipping polygons for each of said display elements in accordance with descendants of said each of said display elements which are not sequential gate elements.
3. The method of Claim 1 further including the step of:
(f) partitioning said resized display elements into a plurality of sets
wherein said resized display elements in a first set do not overlay any of said
resized display elements in a second set.
4. The method of Claim 1 further including the step of:
(g) rendering said resized display elements to said image plane.
5. The method of Claim 3 wherein said memory is coupled to a
plurality of processors further including the step of (h) rendering each of said
sets to said image plane in parallel using said plurality of processors.

6. A system for rendering an image to an image plane in a memory,
said memory coupled to a processor, comprising:
a interpretation module for generating a display list from a PDL file; a preprocessing module for generating an overlay graph fi'om said

display list, defining clipping polygons for each of said display elements in accordance with descendants of said display elements in said overlay graph; resizing said each of said display elements in accordance with said clipping polygons; and
a rendering module for rendering said image to said image plane in accordance with said overlay graph.
7. The system of Claim 6 wherein said preprocessing module includes:
a controller module;
a build graph module coupled to said controller modtile for generating said overlay graph from said display list wherein said overlay graph defines a first display element in said display list as a descendant of a second display element in said display list if said first display element overlays said second display element and said overlay graph defines said first display element as a sequential gate element if said first display element represents a bit-mapped font or a masked pattern;
a dip polygon module coupled to said controller module for generating an associated clipping polygon for each of said display elements in accordance with said descendants which do not represent sequential gate elements;
a resize object module coupled to said controller module for resizing said each of said display elements in accordance with said clipping polygon to

r
generate resized display elements; and
a partition graph module coupled to said controller module for partitioning said resized display elements into a plurality of sets wherein said resized display elements in a first of said sets do not overlap with any of said resized display elements in a second of said sets.
8. The method of Claim 7 wherein said memory is coupled to a plurality of processors, each of said processors executing said rendering module to render said sets to said image plane in parallel.
9. A system for rendering an image to an image plane in a memory substantially as hereinbefore described and with reference to the accompanying drawings.