a data processing system configured as an image processing apparatus is shown in fig1 . the system has a processing unit cpu 10 , arranged to process three dimensional image data to produce for display a two - dimensional view of objects modelled in a virtual - three dimensional world . the cpu 10 is coupled via data and address bus 12 to random access and read - only memories ram 14 and rom 16 and also , via a suitable interface 18 , to a further ( off - line ) data store ols 20 . the ols 20 suitably provides the source of three - dimensional data and instructions controlling the operation of the cpu 10 from a permanent storage device such as a magnetic disc , an optical disc , a magneto - optical disc or other suitable storage medium . the main constraint on the form of ols is that it be capable of supplying data , via the interface 18 and bus 12 , to the cpu 10 at the required rate . also connected to the bus 12 is a frame buffer and display driver stage 22 arranged to generate video images on a connected video monitor vdu 24 . in order to enable user control or contribution for the image generation process , a user input device interface 26 is connected to the bus 12 with input devices such as keyboard 28 and mouse 30 connected to the interface . three dimensional data is stored as definitions of the position of polyhedra vertices in a three - dimensional co - ordinate space . the two - dimensional view of the three - dimensional data generated on vdu 24 , on a frame - by - frame basis , is produced by considering the vertices as being connected by straight lines , thereby defining a net of flat polygons . a view is rendered by considering each polygon in turn , possibly after performing back face culling , etc ., so as to remove polygons which are not visible from the particular view under consideration . thereafter , a list of polygons may be defined , which ensures that the polygons are rendered in the correct order . for the purposes of illustration , a conventional technique for polygon rendering will initially be considered with reference to fig2 which shows a triangular primitive . a common technique for rendering a triangle is to start at the top and draw “ spans ” until the triangle is complete , where a span is that part of a triangle which is covered by one row of screen pixels . the pixels belonging to each span are shown with their span number in fig2 . the processing starts by sorting the three vertices in the vertical ( y ) direction such that there is a top , middle and bottom vertex , shown as v t , v m , and v b . once this has been done the triangle can be classified into one of four categories . if the top and middle vertices have the same y value then it is flat topped , if the middle and bottom have the same y value then it is flat bottomed . if all three vertices have the same y value then the triangle is degenerate and , as will be explained below , need not be drawn . the remaining two cases are the most common for reasonably large triangles , although not necessarily for smaller ones covering only a few pixels , and cover the situation where the three vertices all have different y values . one is the left - split case ( as illustrated in fig2 ) where the left side of the triangle is split into two edges with vertex v m at the junction of these two edges . the right - split case occurs when the right hand edge is split . in each of these four cases ( the degenerate case having been excluded ) all the edge slopes of the primitive are computed . for flat topped and flat bottomed triangles there are two slopes to compute while for the left -/ right - split cases there are three . the procedure for flat - topped triangles of height 2 pixels , width n pixels is to draw a horizontal line of ( n − 1 ) pixels from the left hand vertex . the next case is that of a flat bottomed primitive ( two vertices at y min ) with a height of 2 pixels and any width . the inverse of the previous case , the horizontal line of pixels is now the bottom line of the primitive and is therefore not drawn whilst the single top pixel is to be considered as the right - hand of a span and is similarly not drawn , as indicated by fig5 . the result is accordingly for this case draw nothing . the next case is flat topped ( fig6 ) or flat bottomed ( fig7 ) primitives of width 2 pixels and of any height : note that width here refers to the area covered by the primitive and not horizontal extent ( x max − x min ). here a vector ( i . e . a single line of pixels ) is to be drawn , with only one slope needing to be calculated together with the length of vector to be drawn . there is no need in this case for horizontal slope calculation of , for example , texture values . the final case has a width ( again not horizontal extent ) of 2 pixels and any height , but is neither flat topped nor flat bottomed , as shown in fig8 . in this case , the slopes for all three edges need to be calculated but again there is a saving coming from the fact that the resulting pixel pattern will be a simple line with no horizontal slope calculations required . a generalised selection process for sorting the primitives is shown in the flow chart of fig9 . from the start 40 , an optional first test at step 42 is whether or not the primitive is occluded , for example for hidden surface removal . as will be well understood , the question of occlusion may be more than a simple yes / no test , depending on the total or partial translucency of overlapping primitives , and may comprise a recursive loop test as additional primitives are added to an image , as in the well known z - buffering algorithm , although this will occur after the process of fig8 . if the test at step 42 is included , and indicates the primitive to be occluded , the primitive is discarded ( at 44 ), else it is passed to step 46 . at step 46 , the vertical height ( y max − y min ) is checked and , if equal to one pixel ( i . e . if y max = y min ), the primitive is degenerate and discarded . in like it is important to note that pixels should not be rendered twice where they contain a part on either side of an edge where two triangles join . avoidance of this double rendering is partly to save drawing time but more particularly to eliminate errors which can occur . in particular , if the pixels are translucent , such that the display pixel colour / texture contains contributions from one or more primitives behind the front - most primitive , the relative contributions of the front and overlaid primitives will be miscalculated if the pixel is considered twice . this might result in , for example , a pixel appearing dimmer than it should be . in order to avoid this overlap , it is known to leave the right hand pixel of each span undrawn and to leave the bottom span undrawn such that pixels on the boundary of two primitives will only be considered for one of those two primitives . it is because of this procedural step that the degenerate case above does not need any drawing operations , since it contains only one span , which is the bottom span and hence excluded from consideration . the applicants have recognised that further processing may be saved as a result of this step of not considering certain pixel primitive contributions , by identifying as special cases those primitives capable of simplified treatment having discounted those pixels to be ignored . these special cases , and the simplified treatment each receives , are illustrated in the pixel layout diagrams of fig3 to 8 , in which a 0 represents a pixel covered by the primitive but which is not drawn ( for the reasons explained above ), a 1 represents a pixel which must drawn , and the subscripts ‘ max ’, ‘ mid ’ and ‘ min ’ respectively identify maximum , intervening , and minimum values when applied to screen coordinates at the triangle vertices . the first special case is those primitives having a horizontal top ( two vertices at y max ) and a vertical extent ( y max − y min ) of 2 pixels . where the top width ( x max − x min in this instance ) is 2 pixels , the resultant rendering requires just a single pixel at the vertex location , as shown in fig3 . where the top width is greater than 2 pixels , a simple horizontal line of pixels is required , as shown in fig4 . with the right hand pixel contribution being dropped in all cases , manner , step 48 checks the horizontal extent from the furthest left to the furthest right of the vertices ( x max − x min ) and again , if equal to one pixel , the primitive is degenerate and is discarded . at step 50 , a check is made as to whether the vertical extent is equal to two pixels ( remembering the primitives of height less than or equal to one pixel have already been discarded as degenerate ). if so , step 52 checks whether it is flat - bottomed ( as in fig5 ) and , if so , it is discarded . if the check of step 52 is negative , a further check is made at step 54 as to whether the primitive is flat - topped ( as in fig3 and 4 ) and , if so , the primitive is entered on the rendering list at 56 with the identifier that just a horizontal line need be drawn , from the top left vertex and of length ( v t − v m − 1 ) pixels . if check 54 is also negative , the primitive has no horizontal edge and is entered on the rendering list at 58 with the identifier that no horizontal slope calculation is required . if step 50 is negative , that is to say the vertical extent is greater than two pixels , the horizontal extent is checked at step 60 and , if also greater than two pixels , the primitive does not form one of the special cases . accordingly , the pixel is entered on the rendering list at 62 without any identifier indicating special treatment . if the horizontal extent is less than or equal to two pixels , the next two steps 64 , 66 check whether it is flat - topped ( as in fig6 ) or flat - bottomed ( fig7 ) respectively . if either test holds true , the primitive is entered on the rendering list at 68 with the identifier that a single slope and length need be calculated , as described previously . if the primitive is neither flat - topped nor flat - bottomed , it is entered on the rendering list at 58 with the other primitives identified as being special cases but without a horizontal edge . the benefit of the present invention is to reduce the processing need in these situations . it may be used to enable the use of a less expensive rendering system , to allow the use of more realistic / attractive 3d models , or to enable more objects to be viewed in the distance than would otherwise be possible . from reading the present disclosure , other modifications will be apparent to persons skilled in the art . such modifications may involve other features which are already known in the design , manufacture and use of image processing apparatus and devices and component parts thereof and which may be used instead of or in addition to features already described herein . although claims have been formulated in this application to particular combinations of features , it should be understood that the scope of the disclosure of the present application also includes any novel feature or novel combination of features disclosed herein either explicitly or implicitly or any generalisation thereof , whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention . the applicants hereby give notice that new claims may be formulated to such features and / or combinations of such features during the prosecution of the present application or of any further application derived therefrom .