AU2009251139A1 - Data caching - Google Patents

Abstract

DATA CACHING 5 A method of determining a size of a buffer for storing a plurality of bitmap objects (e.g., 205) is disclosed. A plurality of bitmap portions (e.g., tO to t27) are defined for the plurality of bitmap objects, each bitmap portion having an extent in one dimension. A list of the extents of the bitmap portions are created. A size of the buffer is determined for storing the plurality of bitmap portions using the list. A portion of the buffer stores 10 bitmap portions with non-overlapping extents. Q'OOR7 Finnl - 3/16 270 START 200 Determine height of row of bitmap and height of overlap 271 margin Determine output band corresponding to scanline 272 Add a row to extents table initialise counter,n = 0 Fig 2d Advance to next output ban 73 280 Determine end of previous band Determine start of next band 286 re band numbers I YE S the same ? tNO( Add entry to extents table for starting Add single row to extent ro tableAdd entry to extents table for ending row :re ment = n+1 291 11 bitmap rows 7 L f except for last row 288 292 YES processed ? Add final row to extents table 025v1 ( END

Description

S&F Ref: 930087 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3 of Applicant: chome, Ohta-ku, Tokyo, 146, Japan Actual Inventor(s): Krzysztof Adam Koziarz Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Data caching The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(2458551 1) DATA CACHING Technical Field The present invention relates to graphic object rendering and, more particularly, to efficient rendering of bitmap images subject to affine transformations. The present 5 invention also relates to a method and apparatus for storing a plurality of bitmap objects in a buffer, and to a computer program product including a computer readable medium having recorded thereon a computer program for storing a plurality of bitmap objects in a buffer. Background 10 In banded rendering systems, a page or screen to be output is rendered from display list primitives band by band. Individual rectangular regions of pixels spanning a given number of individual scan lines, or bands, are rendered sequentially. An output area can be divided into bands of a uniform height or the band sizes may vary. Ordinarily, the generation or rendering of output bands is sequential. A 15 complete band of pixels is rendered before rendering the next band. Alternatively, bands may be rendered in parallel, for example, two interleaving bands at a time. Efficient caching of bitmap display list primitives is highly desirable in banded rendering systems. A particularly desirable feature of limited memory systems, for example, is that bitmap display list primitives be stored in a compact form relative to the 20 total size of raw source pixel data. To reduce the size of bitmap primitives in memory, data compression is typically applied to source bitmaps. One known data compression scheme is based on the Joint Photographic Experts Group (JPEG) standard algorithm. The JPEG algorithm divides bitmaps into Minimal Coding Units (MCUs), which are rectangular regions of constant size, otherwise known as source tiles. Each source tile is 25 coded or compressed independently of other source tiles and can also be decompressed independently of other source tiles. Other data compression schemes exist that divide bitmaps into minimal coding units, in a way similar to JPEG. When rendering bitmaps, initially compressed using JPEG or one of the other compression schemes, from a display list, the decompression and caching of an entire 30 compressed bitmap can use a large amount of system resources. In low memory rendering systems, such resources may be unavailable. n 4no..1 0O1A1Q'7 Vn-l -2 Summary It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. 5 According to one aspect there is provided a method of determining a size of a buffer for storing a plurality of bitmap objects, said method comprising: defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; creating a list of the extents of the bitmap portions; and 10 determining a size of the buffer for storing the plurality of bitmap portions using said list, wherein a portion of the buffer stores bitmap portions with non-overlapping extents. According to another aspect, there is provided a system for determining a size of a buffer for storing a plurality of bitmap objects, said system comprising: 15 a memory for storing data and a computer program; a processor coupled to said memory for executing said computer program, said computer program comprising instructions for: defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; 20 creating a list of the extents of the bitmap portions; and determining a size of the buffer for storing the plurality of bitmap portions using said list, wherein a portion of the buffer stores bitmap portions with non overlapping extents. According to still another aspect, there is provided an apparatus for determining a 25 size of a buffer for storing a plurality of bitmap objects, said apparatus comprising: means for defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; means for creating a list of the extents of the bitmap portions; and means for determining a size of the buffer for storing the plurality of bitmap 30 portions using said list, wherein a portion of the buffer stores bitmap portions with non overlapping extents. According to still another aspect, there is provided a computer readable medium comprising a computer program stored thereon for determining a size of a buffer for storing a plurality of bitmap objects, said program comprising: ') cr.:n,, I02'OOR'7 Finnl| -3 code for defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; code for creating a list of the extents of the bitmap portions; and 5 code for determining a size of the buffer for storing the plurality of bitmap portions using said list, wherein a portion of the buffer stores bitmap portions with non overlapping extents. Other aspects are also disclosed. Brief description of the drawings 10 Fig. 1 shows an example of an up-scaled source bitmap; Fig. 2a shows mapping of a source bitmap to output bands, in accordance with one example; Fig. 2b is a table showing the boundaries of bitmap extents for the bitmap of Fig. 2a; 15 Fig. 2c shows memory organisation of the source tile cache for the bitmap of Fig. 2a; Fig. 2d is a flowchart showing a method of creating the table of bitmap extents of Fig. 2b; Fig. 3a shows mapping of column fragments to output bands, in accordance 20 with one example; Fig. 3b is a table showing boundaries of bitmap extents for the bitmap of Fig. 3a; Fig. 3c shows memory organisation of the source tile cache for the bitmap of Fig. 3a; 25 Fig. 3d is a flowchart showing a method of creating the table of bitmap extents of Fig. 3b; Fig. 4a shows a sheared and rotated bitmap that may be split into row fragments and rendered; Fig. 4b shows a sheared and rotated bitmap that can be split into column 30 fragments and rendered; Fig. 5a shows the mapping of source tile fragments to output bands, in accordance with one example; Fig. 5b shows extents of the source tile fragments of the bitmap shown in Fig. 5a, arranged by output bands; -4 Fig. 5c shows memory organisation of the source tile cache for the bitmap shown in Fig. 5a; Fig. 5d is a flowchart showing a method of creating the table of bitmap extents 5 shown in Fig. 5b; Fig. 6 shows combined extents of row fragments, column fragments, and source tile fragments of bitmaps from Figures 2a, 3a, and 5a arranged by output bands; Fig. 7a shows an example of overlapping bitmap cache buffers; Fig. 7b shows an example memory layout of a cache buffer; 10 Fig. 8a shows an example of a page comprising multiple source bitmaps; Fig. 8b shows an example cache buffer for storing bitmaps of the page of Fig. 8a; Fig. 9 is a flowchart showing a method of determining layout of a cache buffer and total size required for the cache buffer; Figs. 10a and 10b collectively form a schematic block diagram of a general 15 purpose computer upon which arrangements described may be practised; and Fig. 11 is a flowchart showing a method of storing a plurality of bitmap objects in a cache buffer. Detailed description 20 Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. Figs. 10a and 10b depict a general-purpose computer system 1000, upon which 25 the various arrangements described can be practiced. As seen in Fig. I Oa, the computer system 1000 includes: a computer module 1001; input devices such as a keyboard 1002, a mouse pointer device 1003, a scanner 1026, a camera 1027, and a microphone 1080; and output devices including a printer 1015, a display device 1014 and loudspeakers 1017. An external Modulator 30 Demodulator (Modem) transceiver device 1016 may be used by the computer module 1001 for communicating to and from a communications network 1020 via a connection 1021. The communications network 1020 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1021 is a telephone line, the modem 1016 may be a traditional 35 "dial-up" modem. Alternatively, where the connection 1021 is a high capacity (e.g., IA AAQoo1 Q0N0R7 Final -5 cable) connection, the modem 1016 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1020. The computer module 1001 typically includes at least one processor unit 1005, 5 and a memory unit 1006. For example, the memory unit 1006 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 1001 also includes an number of input/output (I/O) interfaces including: an audio-video interface 1007 that couples to the video display 1014, loudspeakers 1017 and microphone 1080; an I/O interface 1013 that couples to the keyboard 1002, 10 mouse 1003, scanner 1026, camera 1027 and optionally a joystick or other human interface device (not illustrated); and an interface 1008 for the external modem 1016 and printer 1015. In some implementations, the modem 1016 may be incorporated within the computer module 1001, for example within the interface 1008. The computer module 1001 also has a local network interface 1011, which permits coupling of the computer 15 system 1000 via a connection 1023 to a local-area communications network 1022, known as a Local Area Network (LAN). As illustrated in Fig. 10a, the local communications network 1022 may also couple to the wide network 1020 via a connection 1024, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 1011 may comprise an EthernetTm circuit card, a BluetoothTM 20 wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1011. The /0 interfaces 1008 and 1013 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage 25 devices 1009 are provided and typically include a hard disk drive (HDD) 1010. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1012 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc TM), USB-RAM, portable, external hard drives, and floppy disks, for 30 example, may be used as appropriate sources of data to the system 1000. The components 1005 to 1013 of the computer module 1001 typically communicate via an interconnected bus 1004 and in a manner that results in a conventional mode of operation of the computer system 1000 known to those in the relevant art. For example, the processor 1005 is coupled to the system bus 1004 using a 35 connection 1018. Likewise, the memory 1006 and optical disk drive 1012 are coupled to 1A4An0fQ1 O1AA2Q7 rn;l -6 the system bus 1004 by connections 1019. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or a like computer systems. 5 Methods described below may be implemented using the computer system 1000 wherein the processes of Figs. 2A to 9, to be described, may be implemented as one or more software application programs 1033 executable within the computer system 1000. In particular, the steps of the described methods are effected by instructions 1031 (see Fig. 10b) in the software 1033 that are carried out within the computer system 1000. The 10 software instructions 1031 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user. 15 The software may be stored in a computer readable medium, including the storage devices described below, for example. The software 1033 is typically stored in the HDD 1010 or the memory 1006. The software is loaded into the computer system 1000 from the computer readable medium, and then executed by the computer system 1000. Thus, for example, the software 1033 may be stored on an optically readable disk 20 storage medium (e.g., CD-ROM) 1025 that is read by the optical disk drive 1012. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 1000 preferably effects an advantageous apparatus for implementing the described methods. 25 In some instances, the application programs 1033 may be supplied to the user encoded on one or more CD-ROMs 1025 and read via the corresponding drive 1012, or alternatively may be read by the user from the networks 1020 or 1022. Still further, the software can also be loaded into the computer system 1000 from other computer readable media. Computer readable storage media refers to any storage medium that provides 30 recorded instructions and/or data to the computer system 1000 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1001. 35 Examples of computer readable transmission media that may also participate in the ano a O'AM7 Tinnl -7 provision of software, application programs, instructions and/or data to the computer module 1001 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets 5 including e-mail transmissions and information recorded on Websites and the like. The second part of the application programs 1033 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1014. Through manipulation of typically the keyboard 1002 and the mouse 1003, a user of the 10 computer system 1000 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 1017 and user voice commands input via the microphone 1080. 15 Fig. 10b is a detailed schematic block diagram of the processor 1005 and a "memory" 1034. The memory 1034 represents a logical aggregation of all the memory modules (including the HDD 1009 and semiconductor memory 1006) that can be accessed by the computer module 1001 in Fig. 1Oa. When the computer module 1001 is initially powered up, a power-on self-test 20 (POST) program 1050 executes. The POST program 1050 is typically stored in a ROM 1049 of the semiconductor memory 1006 of Fig. 10a. A hardware device such as the ROM 1049 storing software is sometimes referred to as firmware. The POST program 1050 examines hardware within the computer module 1001 to ensure proper functioning and typically checks the processor 1005, the memory 1034 (1009, 1006), and 25 a basic input-output systems software (BIOS) module 1051, also typically stored in the ROM 1049, for correct operation. Once the POST program 1050 has run successfully, the BIOS 1051 activates the hard disk drive 1010 of Fig. 10 a. Activation of the hard disk drive 1010 causes a bootstrap loader program 1052 that is resident on the hard disk drive 1010 to execute via the processor 1005. This loads an operating system 1053 into 30 the RAM memory 1006, upon which the operating system 1053 commences operation. The operating system 1053 is a system level application, executable by the processor 1005, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

-8 The operating system 1053 manages the memory 1034 (1009, 1006) to ensure that each process or application running on the computer module 1001 has sufficient memory in which to execute without colliding with memory allocated to another process. 5 Furthermore, the different types of memory available in the system 1000 of Fig. 1 Oa must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1034 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1000 and how such is used. 10 As shown in Fig. 10b, the processor 1005 includes a number of functional modules including a control unit 1039, an arithmetic logic unit (ALU) 1040, and a local or internal memory 1048, sometimes called a cache memory. The cache memory 1048 typically includes a number of storage registers 1044 - 1046 in a register section. One or more internal busses 1041 functionally interconnect these functional modules. The 15 processor 1005 typically also has one or more interfaces 1042 for communicating with external devices via the system bus 1004, using a connection 1018. The memory 1034 is coupled to the bus 1004 using a connection 1019. The application program 1033 includes a sequence of instructions 1031 that may include conditional branch and loop instructions. The program 1033 may also include 20 data 1032 which is used in execution of the program 1033. The instructions 1031 and the data 1032 are stored in memory locations 1028, 1029, 1030 and 1035, 1036, 1037, respectively. Depending upon the relative size of the instructions 1031 and the memory locations 1028-1030, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1030. Alternately, an 25 instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1028 and 1029. In general, the processor 1005 is given a set of instructions which are executed therein. The processor 1105 waits for a subsequent input, to which the processor 1005 30 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1002, 1003, data received from an external source across one of the networks 1020, 1002, data retrieved from one of the storage devices 1006, 1009 or data retrieved from a storage medium 1025 inserted into the corresponding reader 1012, all 35 depicted in Fig. 10a. The execution of a set of the instructions may in some cases result '%ArCAnO-. Q13007 Final -9 in output of data. Execution may also involve storing data or variables to the memory 1034. The disclosed arrangements use input variables 1054, which are stored in the 5 memory 1034 in corresponding memory locations 1055, 1056, 1057. The arrangements produce output variables 1061, which are stored in the memory 1034 in corresponding memory locations 1062, 1063, 1064. Intermediate variables 1058 may be stored in memory locations 1059, 1060, 1066 and 1067. Referring to the processor 1005 of Fig. 10b, the registers 1044, 1045, 1046, the 10 arithmetic logic unit (ALU) 1040, and the control unit 1039 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 1033. Each fetch, decode, and execute cycle comprises: (a) a fetch operation, which fetches or reads an instruction 1031 from a memory 15 location 1028, 1029, 1030; (b) a decode operation in which the control unit 1039 determines which instruction has been fetched; and (c) an execute operation in which the control unit 1039 and/or the ALU 1040 execute the instruction. 20 Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 1039 stores or writes a value to a memory location 1032. Each step or sub-process in the processes of Figs. 2a to 9 is associated with one or more segments of the program 1033 and is performed by the register section 1044, 25 1045, 1047, the ALU 1040, and the control unit 1039 in the processor 1005 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1033. The described methods may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the 30 methods. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories. The described methods may be used with a cache buffer, for storing source tiles, which is substantially smaller than the size of uncompressed source bitmap data coming from input display list primitives. For the described methods, run-time behaviour of the 35 cache buffer is optimal with respect to fetching efficiency. Each source tile is fetched, -- enan- 0100R7 Final - 10 decompressed, and stored in the cache buffer once. Efficient source bitmap fetching is important since such fetching is usually a slow operation compared to the rest of a rendering process, so any repeated source data fetching should be kept to a minimum. 5 Further, each source tile of a bitmap is read from a predetermined location within the cache buffer. The overall size of the cache buffer is predetermined during analysis of an input display list. The size and location of the cache buffer stays constant during rendering. In a display list, a bitmap may have one or more associated affine transforms that 10 describe the transformation from source pixel space to output pixel space. The general form of an affine transform is given by Equation (1), as follows: [x]= [ ][u]+ Eqn. 1 y B D v t 15 where: defines the location of a pixel in the source pixel space; defines the location of a transformed pixel in the output pixel space; [ defines bitmap translation in the output pixel space; and .t [ ] is the transformation matrix. 1B D_ 20 Equation (2), below, may be used during output image rendering to determine a source bitmap pixel required to render any given output pixel: [ti=[a c[ ; 1 E Eqn. 2 v b d_ y-t_ 25 where: 'MMtAnOR111 O'A('7 TPnal - 11 ~a c~ is the inverse of the transformation matrix. .b d _ Fig. 1 shows a source bitmap 100 which has been up-scaled and positioned onto 5 a page to be rendered. The dashed lines 110, 120 and 130 in Fig. 1 represent band boundaries for the output pixel space. In the example of Fig. 1, scaled source tiles are taller than output bands. As shown in Fig. 1, output band 115, between scan lines 110 and 120, intersect source bitmap source tiles 140 to 155 and 160 to 175. Each of the source tiles 140 to 155 and 160 to 175 needs to be available (e.g., to the processor 1005 10 executing rendering) in order to render output band 115. When rendering moves to a next output band, for example band 125 between the scan lines 120 and 130, a different set of source tiles needs to be available for rendering (i.e., source tiles 160 to 175). Fetching and decompressing bitmap data and placing the uncompressed data into a cache buffer are costly operations. In the described methods, the number of times a 15 source tile is decompressed is minimized during the course of rendering. Each source tile is decompressed and stored in the cache buffer once, without the need to copy or move cached data. A rendering engine (e.g., under execution of the processor 1005) reading the cached pixel data may be simplified as a result of source bitmap caching. In the described methods, source bitmaps within an input display list are 20 decomposed into source tiles, where all the source tiles of each bitmap have the same pixel dimensions. Each source bitmap has an associated affine transform. Output bands are rendered in a row sequential or column sequential manner. Each output band is rendered to completion before the rendering of a next band commences. The affine transforms, in one embodiment, are such that, for row sequential or 25 column sequential output band rendering, source tiles may be fetched in either a row sequential or column sequential manner. A method 200 of creating a table of bitmap extents, will be described below with reference to Figs. 2a to 2d. Another method 300 of creating a table of bitmap extents, will be described below with reference to Figs. 3a to 3d. Still another method 500 of 30 creating a table of bitmap extents, will be described with reference to Figs. 5a to 5d. A method 900 of determining layout of a cache buffer and total size required for the cache buffer will also be described by way of example with reference to Figs. 8a, 8b and 9. Finally, a method 1100 of storing a plurality of bitmap objects in a cache buffer will be described with reference to Fig. 11. nAroAnO. I Q100R7 Final - 12 The described methods may be used for storing a plurality of bitmaps (or bitmap objects) in a buffer by defining a plurality of source tiles. As described above, the source tiles may also be referred to as "minimal coding units (MCU)" for the plurality of 5 bitmaps. Further, the source tiles may also be referred to as "bitmap portions". Each source tile has an extent in one horizontal or vertical dimension as described below. The methods may be used for creating a table (or list) of the extents of the source tiles (or bitmap portions) and determining a size of the buffer for storing one of the plurality of source tiles (or bitmap portions) using the table (or list) of extents. The table of extents 10 may also be referred to as a list of extents. The table of extents (or list) may be ordered in rendering band order. A portion of the buffer may be configured to store bitmap portions with non-overlapping extents. The methods may then be used for storing the plurality of bitmaps (or bitmap objects) in the buffer, based on the table (or list) of extents. The methods 200 and 300 described below are applicable to affine transforms 15 where at least one, and at most two, of the coefficients a, b, c and d in Eqn. 2. are equal to zero or close to zero. In this instance, at least one of pixel coordinates u and v in the source pixel space remains constant, or almost constant, as rendering is performed either on x (horizontal) or y (vertical) axis in the output pixel space. Suitable affine transforms are described below in cases (1) to (6), where translation terms in Eqn. (1) and Eqn. (2) 20 are ignored: (1) a = 0 or a = 0, and b, c, df 0: From Eqn. 2, u = cy and v = bx + dy. If output pixel coordinate x is varied while keeping output pixel coordinate y constant, input pixel coordinate u will remain constant while input pixel coordinate v varies. If the output is 25 rendered in a row sequential manner, then the input bitmap will be read in a column sequential manner. However, if the output pixel coordinate y is varied while keeping the output pixel coordinate x constant, both the input pixel coordinates u and v will vary. Hence, the methods 200 and 300 are not applicable if the output is rendered in a column sequential manner when 30 coefficient a in Eqn. 2 is equal to zero or close to zero, i.e., coefficients b, c and d are non-zero. (2) b = 0 or b ~ 0, and a, c, d 10: From Eqn. 2, u = ax + cy and v = dy. If the output pixel coordinate x is varied while keeping the output pixel coordinate y constant, the input pixel 35 coordinate v will remain constant while the input pixel coordinate u varies. O'n0R7 Final - 13 If the output is rendered in a row sequential manner, then the input bitmap will be read in a row sequential manner. However, if the output pixel coordinate y is varied while keeping the output pixel coordinate x constant, 5 both the input pixel coordinates u and v will vary. Hence, the methods 200 and 300 described below are not applicable if the output is rendered in a column sequential manner when the coefficient b in Eqn. 2 is equal to zero or close to zero, i.e., coefficients a, c and d are non-zero. (3) c = 0 or c = 0, and a, b, d # 0: 10 From Eqn. 2, u = ax and v = bx + dy. If the output pixel coordinate y is varied while keeping the output pixel coordinate x constant, the input pixel coordinate u will remain constant while the input pixel coordinate v varies. If the output is rendered in a column sequential manner, then the input bitmap will be read in a column sequential manner. However, if the output 15 pixel coordinate x is varied while keeping the output pixel coordinate y constant, both the input pixel coordinates u and v will vary. Hence, the methods 200 and 300 described below are not applicable if the output is rendered in a row sequential manner when the coefficient c in Eqn. 2 is equal to zero or close to zero, i.e., coefficients a, b and d are non-zero. 20 (4) d= 0 or d= 0, and a, b, c # 0: From Eqn. 2, u = ax + cy and v = bx. If the output pixel coordinate y is varied while keeping the output pixel coordinate x constant, the input pixel coordinate v will remain constant while the input pixel coordinate u varies. If the output is rendered in a column sequential manner, then the input 25 bitmap will be read in a row sequential manner. However, if the output pixel coordinate x is varied while keeping the output pixel coordinate y constant, both the input pixel coordinates u and v will vary. Hence, the methods 200 and 300 are not applicable if the output is rendered in a row sequential manner when the coefficient d in Eqn. 2 is equal to zero or close 30 to zero, i.e., coefficients a, b and c are non-zero. (5) a, d = 0 or a, d = 0, and b, c# 0: From Eqn. 2, u = cy and v = bx. If the output pixel coordinate x is varied while keeping the output pixel coordinate y constant, the input pixel coordinate u will remain constant while the input pixel coordinate v varies. 35 If the output is rendered in a row sequential manner, then the input bitmap 930087 Final - 14 will be read in a column sequential manner. Alternatively, if the output pixel coordinate y is varied while keeping the output pixel coordinate x constant, the input pixel coordinate v will remain constant while the input 5 pixel coordinate u varies. Hence, if the output is rendered in a column sequential manner, then the input bitmap will be read in a row sequential manner. (6) b,c=Oorb,c ~0,anda,d#0: From Eqn. 2, u = ax and v = dy. If the output pixel coordinate x is varied 10 while keeping the output pixel coordinate y constant, the input pixel coordinate u varies while the input pixel coordinate v remains constant. Hence, if the output is rendered in a row sequential manner, then the input bitmap will be read in a row sequential manner. Alternatively, if the output pixel coordinate y is varied while keeping the output pixel coordinate x 15 constant, the input pixel coordinate v varies while the input pixel coordinate u remains constant. Hence, if the output is rendered in a column sequential manner, then the input bitmap will be read in a column sequential manner. The method 200 of creating the table of bitmap extents will now be described 20 with reference to Figs. 2a to 2d. The method 200 may be implemented as one or more code modules of the software application program 1033 resident on the hard disk drive 1010 and being controlled in its execution by the processor 1005. The method 200 generates output bands in row sequential order using a source bitmap (or bitmap object) having an inverse affine transform with matrix coefficients b 25 and c from Eqn. 2 both set to zero (0) in accordance with case (6) above. As such, the source bitmap is scaled without rotation or shear. If the matrix coefficients a and d are between zero (0) and one (1), the bitmap is up-scaled. In this instance, the rendering of a single output band requires up to two rows of source tiles. If the matrix coefficient a or d in the direction of rendering is more than one (1), the bitmap is downscaled. As a result, 30 the rendering of a single output band may require more than two rows of source tiles. Fig. 2a shows the mapping of a source bitmap 205 to output bands, in accordance with one example. The source bitmap 205 comprises twelve (12) source tiles tO to t11, arranged in three rows marked zero (0) through two (2), and four columns marked zero (0) through three (3). Each source tile tO to t1 I represents a portion of the 35 bitmap 205 or bitmap portion. The bitmap 205 is mapped to the output image in such I el^nnQ - 010M7 Firnnl - 15 way that the output bands S-0 to S-5 are intersected by a transformed bitmap. Output band boundary scan lines are marked with dashed lines 201-204. The first band intersecting the bitmap 205 is band S-0, bounded by scan lines 201 and 202. Just before 5 the start of rendering the output band S-0, source pixels of bitmap 205 must be available for rendering, so the bitmap 205 must be brought to a cache buffer configured within cache memory 1048. The last band intersecting the source bitmap 205 is band S-5, bound by scan lines 203 and 204. Just after the end of rendering the output band S-5, source pixels of bitmap 205 do not need to be available for rendering, so the bitmap 205 can be 10 released or the cache buffer for the bitmap 205 occupied by the bitmap 205 can be reused for other purposes. While rendering output bands S-0 and S-1, a single row, row 0, comprising source tiles tO through t3, needs to be available for rendering. While rendering output band S-2, two rows (i.e., row 0 and row 1) comprising source tiles tO through t7, need to 15 be available for rendering. While rendering output band S-3, a single row, row 1, comprising source tiles t4 through t7, needs to be available for rendering. After output band S-2 is rendered, source tiles tO through t3 are no longer needed and the cache buffer in the cache memory 1048 occupied by source tiles tO through t3 can be reused for other purposes. While rendering output band S-4, two rows (i.e., row I and row 2) comprising 20 source tiles t4 through t1, need to be available for rendering. Finally, while rendering output band S-5, a single row, row 2, comprising source tiles t8 through t1l, needs to be available for rendering. In the example of Fig. 2a, at most two rows of source tiles are required at any point during rendering in order to render the bitmap 205. Therefore, the size of the cache 25 buffer, configured within cache memory 1048, required to hold data of the source bitmap 205 for rendering is two rows of four (4) source tiles each (i.e., eight (8) tiles) which is less than the size of the full bitmap 205. It may be determined, in the example of Fig. 2a, for each row of source tiles, when each source tile is to be available for rendering, and when each tile no longer needs 30 to be available. For example, row 0 needs to be made available before rendering strip S-0, and no longer needs to be available after rendering strip S-2. The range of output (or rendering) bands during which a given source bitmap row (or bitmap portion) is to be available for rendering is referred to as "bitmap extents". The bitmap extents of a source tile in one dimension, in one embodiment, are the range of rendering bands that the source 35 tile overlaps. Therefore, the bitmap extents of row 0 in Fig. 2a are bands S-0 to S-2 in I 0100R7 Finmi -16 the vertical dimension. Further, the bitmap extents of row 1 in Fig. 2a are rendering strips S-2 to S-4. Fig. 2b is a table listing boundaries of bitmap extents of the bitmap 205. The 5 table of Fig. 2b is a list of the extents for the source tiles (or bitmap portions) of the bitmap 205. The method 200 may be used for creating the list of extents (i.e., the table of Fig. 2b) of the source tiles (or bitmap portions), as described below. Each line in the table of Fig 2b shows bitmap row extents starting and ending on a given output band. The table of Fig. 2b consists of three columns as follows: 10 e Output Band column: showing band number; " Row needed column: indicating Output Band is start extent of row number Row needed; and " Row ending column: indicating Output Band is the end extent of row number Row ending. 15 The table of Fig. 2b is sorted by output band number. For example, the second line in the table of Fig. 2b specifies that output band S2 marks the start of the extent of row 1 and the end of the extent of row 0. End extent 210 at band SO does not exist, because there is no bitmap data that is no longer required after band SO. The value "-1" in 20 column three (3) of the table indicates that there is no extent end at band SO. Start extent 220 at band S5 does not exist, because no new bitmap data is required onwards from band S5. The value "-2" indicates that there is no extent starting at band S5. The method 200 will now be described by way of example with reference to the bitmap 205 and the extents table of Fig. 2b. The method 200 begins at height determining 25 step 270, where the processor 1005 determines height ("row-height") of a row of the bitmap 205 in output band units. The determined height may be stored in the memory 1006. The bitmap row height, rowheight, is determined by multiplying coefficient D of the bitmap affine transform given in Eqn. I by the height of a source tile (or "minimal coding unit" (i.e., row height = D * MCU height). 30 In addition to the bitmap row height, at step 270, the processor 1005 determines the height of an overlap margin ("margin-height") between two bitmap rows in output band units. The overlap margin is needed for output interpolation. When rendering pixels mapping to points in the source bitmap near the border of a source tile (or bitmap portion), some pixels from the neighbouring source tile may be needed. Therefore, nA CeAAO..1 930087 Final - 17 overlap margin, margin-height, may be determined by multiplying the coefficient D of the bitmap affine transform by the number of additional source pixels ("i-pixels") needed for interpolation (i.e., margin-height = D * ipixels). In a nearest neighbour linear 5 interpolation, a single pixel is needed, where ipixels = one (1). In addition, a variable, currentline, configured within memory 1006 is set to the value of the first scan line on which the rendered bitmap 205 will appear (i.e., currentline = Ystart). The variable currentline corresponds to translation term t from Eqn. 1. At a next output band determining step 271, the output band corresponding to 10 scan line, currentline, is determined by the processor 1005, by dividing current-line by the output band height (i.e., next_band = currentline/band height). Then at a next row adding step 272, the processor 1005 adds a row to the extents table (i.e., ADDROW(next-band, row(0), -1)). ADDROW represents a subroutine that adds an entry to the extent table configured within memory 1006 with: a first argument being the 15 output band (which is set to next-band), a second argument being the starting row, and a third argument being the ending row. For the band determined in step 271, row number zero (0) is the starting row and there is no ending row. Thus, the value "-1" is stored to indicate the absence of a value for the ending extent. For example, the ending row value 210 in the first row of the extents table shown in Fig. 2b has the value "-1" as ending 20 extent. At counter initialising step 273, the processor 1005 initializes a counter n, for iterating over the rows of source tile (or bitmap portions) in the bitmap (or bitmap object) 205, to zero (0). Then at next adding step 280, the processor 1005 advances to the next output band by adding row height to currentline (i.e., currentline + rowheight). At 25 following end determining step 281, the processor 1005 determines the end of the previous band by determining the band of the scanline (current-line) incremented by margin-height (i.e., endband = determineband(currentjline + margin height)). Then at start determining step 282, the processor 1005 determines the start of the next band (i.e., nextband = determineband(currentline - margin-height)). The bands 30 may overlap by the margin, margin-height, used for interpolation, calculated in step 270. At decision step 285, if the processor 1005 determines that the band numbers for the previous band and the next band are the same (i.e., endband =- nextband), then the method 200 proceeds to step 286. Otherwise, the method 200 proceeds to step 287. At row adding step 286, a single row is added to the extents table configured 35 within the memory 1006. The row is added for the next band, whose number was 930087 Final - 18 determined in step 282, with row n+1 as starting row and row n as ending row (i.e., ADDROW(next band, row(n+1), row(n))). For example, for bitmap 205, at adding step 286 the processor 1005 adds data comprising output band S2, starting row one (1) and 5 ending row zero (0) as the second row in the extents table in Fig. 2b. At entry adding step 287, an entry is added to the extents table, configured within the memory 1006, for the starting row n+l (i.e., ADDROW(next band, row(n+1), -1 )). Then, at entry adding step 288, an entry is added to the extents table, configured within memory 1006, for the ending row n (i.e., ADDROW(end band, -1, 10 row(n))). Next, at decision step 290, if the processor 1005 determines that all bitmap rows except the last one have been processed (i.e., n < bitmap rows - 1), then the method 200 proceeds to step 292. Otherwise, if any more source bitmap rows apart from the last row remain to be processed, then the method 200 proceeds to step 291. At counter 15 incrementing step 291, processor 1005 increments the counter n by one (1) (i.e., n=n+1), the next source bitmap row is examined and the method 200 loops back to step 280. Otherwise, when only the last bitmap row remains to be processed, at decision step 290 the processor 1005 directs the method 200 to adding row step 292. At row adding step 292, the processor 1005 adds the final row to the extents table indicating the 20 termination of last bitmap row at the last band the bitmap covers (i.e., ADD_ROW(determine band(Yend), -2, row(n)) ). In step 292, the processor 1005 places value "-2" as start extents to indicate the end of bitmap 205. For example, the start row 220 in the last row in the table of Fig. 2b has the value "-2" as starting extent. Memory organization of a cache buffer for source tiles of the bitmap 205 as well 25 as the sequence of fetching the source bitmap data into the cache buffer, while rendering the output bands, will now be described with reference to Fig. 2c. Because the size of the cache buffer for bitmap 205 (i.e., eight (8) source tiles) is smaller, in the example of Fig. 2a to 2d, than the overall bitmap size (i.e., twelve (12) tiles) some uncompressed bitmap data overwrites previously uncompressed bitmap data during rendering. The cache buffer 30 for the bitmap 205 is organized in pixel row sequential order so as to aid quick access to a source bitmap pixel, given a particular output pixel. As seen in Fig. 2c, the cache buffer configured within memory 1048 is divided into two blocks marked rO, rl. Pixels 250 and 260 are the first pixels of each block rO and rl, respectively. Pixel 260 comes right after the last pixel 251 of block rO. Each block rO and r1 is capable of holding the pixels of - I ---- -Q10OR7 Finni -19 four source tiles (i.e., one row of source tiles). The pixels in each row within each of the blocks rO and rl are stored in pixel row sequential order, with a row step equal to the number of source tiles per row, multiplied by the source tile width in pixels. 5 The sequence of steps for loading the cache buffer with appropriate source data for the bitmap 205 at the appropriate time is determined using the data from table (or list) of extents of Fig. 2b. Before rendering of output band SO commences, block rO is loaded with data from rowO of bitmap 205 comprising source tiles tO through t3. As described above, the 10 source tiles tO through t3 may also be referred to as "bitmap portions" or "minimal coding units". Before rendering of output band S2 commences, block rI is loaded with data from rowO of bitmap 205 comprising source tiles t4 through t7. After rendering of output band S2 is complete and before rendering of output band S4 commences, block rO is loaded with data from row2 of bitmap 205 comprising source tiles t8 through t1 1, overwriting the 15 existing data from rO comprising source tiles tO through t3 that are no longer needed. The address Addr of the source pixel in the cache buffer for the bitmap 205 may be determined based on the source pixel coordinates (v, u) of the bitmap, in accordance with Equation (3), as follows: Addr=A0+(L- u-jmodr)R+v, Eqn.3 H 20 where AO is the address of pixel 250, which is the beginning of the cache buffer, His the height of the source tile in pixels, r is the size of the cache in rows, for example r = 2 for bitmap 205, and R is the row-step of the blocks rO and rl, as described above. 25 The method 300 of creating a table (or list) of bitmap extents, will now be described with reference to Figs. 3a to 3d. The method 300 may be implemented as one or more code modules of the software application program 1033 resident on the hard disk drive 1010 and being controlled in its execution by the processor 1005. The method 30 300 generates output bands in row sequential order using a source bitmap (or bitmap object) having a corresponding inverse affine transform with matrix coefficients a and d from Eqn. 2 both set to zero (0) in accordance with case (5) above. If the matrix coefficient b is greater than one (1), the matrix represents a downscaling of the source bitmap in the direction of band rendering with ninety (90) degree rotation. In such an 1 930087 Final - 20 example, the rendering of a single output band requires at least three columns of source tiles. Fig. 3a shows the mapping of a source bitmap 305 (or "bitmap object") to output 5 bands, in accordance with another example. The source bitmap 305 comprises twenty eight (28) source tiles (or bitmap portions) marked tO to t27, arranged in four rows marked zero (0) to three (3) and seven columns marked zero (0) to (6). Each tile tO to t27 represents a portion of the bitmap 305. The bitmap 305 is mapped to the output image in such way that the output bands marked S-0 through S-6 are intersected by a transformed 10 bitmap. Output band boundary scan lines 301-304 are marked with dashed lines. The first band intersecting the source bitmap 305 is band S-0, bounded by scan lines 301 and 302. Just before the start of rendering the output band S-0, certain source pixels of bitmap 305 need to be available for rendering , so the source tiles (or bitmap portions) containing those pixels need to be brought to a cache buffer configured within cache memory 1048 15 for the bitmap 305. The last band intersecting the source bitmap 305 is band S-6, bounded by scan lines 303 and 304. Just after the end of rendering the output band S-6, source pixels of bitmap 305 no longer need to be available for rendering, so the cache buffer occupied by pixels of bitmap 305 may be released or reused for other purposes. While rendering output band S-0, a single column, column 0, comprising source 20 tiles tO, t7, t14 and t21, needs to be available for rendering. While rendering output band S-1, two columns of source tiles (i.e., column 0 and column 1), comprising further source tiles t1, t8, t15, and t22 need to be available for rendering. While rendering output band S-2, source bitmap column 1 and column 2 need to be available for rendering. Source tiles tO, t7, t14 and t21 are no longer needed and the cache memory 1048 occupied by source 25 tiles tO, t7, t14 and t21 may be reused for other purposes. While rendering output band S 3, two columns of source tiles (i.e., column 2 and column 3), need to be available for rendering. Source tiles t1, t8, t15 and t22 are no longer needed and the cache memory 1048 occupied by source tiles t1, t8, t15 and t22 can be reused for other purposes. While rendering output band S-4, three columns of source tiles (i.e., columns 3, 4 and 5), need to 30 be available for rendering. While rendering output band S-5, two columns of source tiles (i.e., column 5 and column 6), need to be available for rendering. Finally, while rendering output band S-6, a single column of source tiles (i.e., columns 6 comprising source tiles t6, t13, t20 and t27), need to be available for rendering. In the example of Fig. 3a, at most three source tile columns (or columns of 35 bitmap portions) are required at any point during rendering of the bitmap 305, with the Q300R7 Final -21 maximum columns required occurring while rendering output band S-4. Therefore, the size of the cache buffer, configured within cache memory 1048, required to hold the source bitmap data for rendering the bitmap 305 is three source tile columns (or twelve 5 (12) tiles), which is less than the size of the full bitmap 305. It may be determined, in the example of Fig. 3a, for each column of source tiles, when the source tiles need to be available for rendering and when each column is no longer required. For example, column zero (0) needs to be made available before rendering strip S-0, and no longer needs to be available after rendering strip S-1. As 10 similarly described with reference to Fig. 2a, the set of output bands where a given source bitmap column needs to be available for rendering is called the "bitmap extents". Therefore, the bitmap extents of column 0 in Fig. 3a are bands S-0 to S-1 in the vertical direction. Fig. 3b is a table listing boundaries of bitmap extents of bitmap 305. The table of 15 Fig. 3b forms a list of the extents of the bitmap portions of the bitmap 305. The method 300 may be used for creating the table (or list) of extents of the bitmap portions, as described below. Each line in the table of Fig. 3b shows bitmap column extents starting and ending on a given output band. The table comprises three columns, as follows: * Output Band column: showing band number; 20 * Column needed column: indicating Output Band is the start extent of column number Column needed; and * Column ending column: indicating Output Band is the end extent of column number Column ending. 25 The table of Fig. 3b is sorted by output band number. For example, the second line in the table of Fig. 3b specifies that output band S1 marks the start of the extent of column one (1) and the end of the extent of column zero (0). End extent 310 at band SO does not exist because there is no bitmap data that is no longer required after band SO. The value "-1" in the table of Fig. 3a marks the fact that there is no extent end at band 30 SO. The start extent 320 at band S6 does not exist, because no new bitmap data is required onwards from band S6. The value "-2" marks the fact that there is no extent starting at band S6. The method 300 will now be described by way of example with reference to the bitmap 305 and the extents table of Fig. 3b. The method 300 begins at height determining o..,O I 9300R7 Final - 22 step 370, where the processor 1005determines the height ("columnheight") of a column of the bitmap 305 in output band units. The determined height may be stored in the memory 1006. The bitmap column height, columnheight, is determined by multiplying 5 the coefficient B of the bitmap affine transform given in Eqn. I by the width of a source tile (or minimal coding unit) (i.e., column height = B * MCU width). In addition to the bitmap column height, at step 370, the processor 1005 determines the height of an overlap margin ("margin-height") between two bitmap columns in output band units. As described above, the overlap margin is needed for 10 output interpolation. When rendering pixels mapping to points in the source bitmap near the border of a source tile (or bitmap portion), some pixels from the neighbouring source tile may be needed. Therefore, overlap margin, marginheight, may be determined by multiplying the coefficient B of the bitmap affine transform by the number of additional source pixels ("ipixels") needed for interpolation (i.e., margin-height = B * ipixels). In 15 a nearest neighbour linear interpolation, a single pixel is needed, in which case i-pixels = one (1). In addition, a variable, currentline, configured within memory 1006 is set to the value of the first scan line on which the rendered bitmap 305 will appear (i.e., i.e., currentline = Ystart). As described above, the variable currentline corresponds to translation term t from Eqn. 1. 20 At a next output band determining step 371, the output band corresponding to the scan line, currentline, is determined by the processor 1005, by dividing current-line by the output band height (i.e., nextband = determineband(current line) = currentline/bandheight)). Then at row adding step 372, the processor 1005 adds a column to the extents table (i.e., ADDROW(nextband, column(0), -1)), configured 25 within memory 1006, for the band determined in step 371, with column number 0 as starting column and no ending column. The value "-1" is stored to indicate the absence of a value for the ending extent. For example, the ending column value 310 in the first row of the extents table shown in Fig. 3b has the value "-1" as ending extent. At counter initialising step 373, the processor 1005 initializes a counter n, for 30 iterating over the columns of source tiles (or bitmap portions) in the bitmap 305, to zero (0). Then at adding step 380, the processor 1005 advances to the next output band by adding the current height, columnheight, to the current scan line, currentline (i.e., currentline + column-height). At following end determining step 381, the processor 1005 determines the end of the previous band by determining the band of the scanline 35 (current line) incremented by margin-height (i.e., endband = mnACAnQ1 930087 Final -23 determine band(currentline + margin-height)). Then at start determining step 282, the processor 1005 determines the start of the next band (i.e., next-band = determine band(currentline - margin-height)). The bands may overlap by the margin, 5 margin-height, used for interpolation, calculated in step 370. At decision step 385, if the processor 1005 determines that the band numbers for the previous band and the next band are the same (i.e., endband == nextband), then the method 300 proceeds to adding step 386. Otherwise, the method 300 proceeds to step 387. At row adding step 386, a single row is added to the extents table configured 10 within the memory 1006. The row is added for the next band, whose number was determined in determining step 382, with column n+l as starting column and column n as ending column (i.e., ADDROW(next band, column(n+1), column(n))). For example, in case of bitmap 305, at adding step 386 the processor 1005 adds the data comprising output band SI, starting column I and ending column 0 as the second row in the extent 15 table in Fig. 3b. At entry adding step 387an entry is added to the extents table, configured within the memory 1006. for the starting column n+l (i.e., ADDROW(nextband, -1, column (n))). Then, at step 388, an entry is added to the extents table, configured within memory 1006,for the ending column n (i.e., ADDROW(endband, column(n+1), -1)). 20 Next, at decision step 390, if the processor 1005 determines that all bitmap columns except the last one have been processed (i.e., n < bitmap columns - 1), then the method 200 proceeds to step 392. Otherwise, if any more source bitmap columns apart from the last column remain to be processed, then the method 300 proceeds to step 391. At counter incrementing step 391, processor 1005 increments the counter n by one (1) 25 (i.e., n=n+1), the next source bitmap column is examined and the method 300 loops back to step 380. Otherwise, when only the last bitmap column remains to be processed, decision step 390 directs the method 300 to step 392. At row adding step 392, the processor 1005 adds the final row to the extents table indicating the termination of last bitmap column at 30 the last band the bitmap covers (i.e., ADDROW(determine band(Yend), -2, column (n)) ). In step 392, the processor 1005 places value -2 as start extents to indicate the end of bitmap 305. For example, the start column 320 in the last row in the table of Fig. 3b has the value -2 as starting extent. Memory organization of the cache buffer for source tiles of the bitmap 305 as 35 well as the sequence of fetching the source bitmap data into the cache buffer for the I 0-300R7 Final - 24 bitmap 305, while rendering the output bands, will now be described with reference to Fig. 3c. Because the size of the cache buffer for the bitmap 305 (i.e., twelve (12) tiles) is smaller, in the example of Fig. 3a to 3d, than the overall bitmap size (twenty-eight (28) 5 tiles) some of the source bitmap data overwrites the existing bitmap data during rendering. The cache buffer for the bitmap 305 is organized in pixel row sequential order so as to aid quick access to a source bitmap pixel, given a particular output pixel. As seen in Fig. 3c, the cache buffer configured within cache memory 1048 for the bitmap 305 is divided into three (3) blocks marked cO, cl and c2. Pixels 350, 360 and 361 are the 10 first pixels of each block, respectively. Pixel 360 comes right after the last pixel 351 of block cO and pixel 361 comes right after the last pixel 361 of block cl. Each block is capable of holding the pixels of four source tiles (i.e., one column of source tiles). The pixels in each column within each of the blocks cO and ci are stored in pixel row sequential order, source tile by source tile, with a row step equal to the source tile width 15 in pixels. The sequence of steps for loading the cache buffer with appropriate source data for the bitmap 305 at the appropriate time is determined by the data from table Fig. 3b. Before rendering output band SO, block cO is loaded with data from column 0 of the bitmap 305, comprising source tiles tO, t7, t14 and t21. Before rendering the output 20 band Si, block c1 is loaded with data from column one (1) of the bitmap 305, comprising source tiles tl, t8, t15 and t22. Before rendering the output band S2, block c2 is loaded with data from column two (2) of the bitmap 305, comprising source tiles t2, t9, 16 and t22. After rendering output band SO is complete and before rendering output band S3, block cO is loaded with data from column three (3), comprising source tiles t3, t10, 017 25 and t24, overwriting the existing data of column zero (0) of the bitmap 305, which contained source tiles tO, t7, t14 and t21 that are no longer needed. After rendering output band S3 is complete and before rendering output band S4, block cl is loaded with data from column four (4) of the bitmap 305, overwriting the existing data in block cl, which is no longer needed; and block c2 is loaded with data from column five (5) of the bitmap 30 305, overwriting the existing data in block c2, which is no longer needed. For the example of Fig. 3a to 3d, the address Addr of the source pixel in the cache buffer for the bitmap 305 may be determined based on the source pixel coordinates (v, u) of the bitmap, in accordance with Equation (4), as follows: Addr = BO+(L v J mod c) +uW +v, Eqn. 4 tHW ,------ - o2007 Finn] - 25 where BO is the address of pixel 350, which is the beginning of the cache buffer for the bitmap 305, 5 H is the height of the source tile in pixels, W is the width of the source tile in pixels, c is the size of the cache buffer for the bitmap 305 in columns, for example c = 3 for bitmap 305, and t is the number of source tiles in each column in the bitmap, for example t = 4 for 10 bitmap 305. The method 200 may be applied to the rendering of sheared bitmaps where row sequential or column sequential output band rendering results in fetching of source tiles in a row sequential manner. Such a situation occurs in cases (2) and (4), referred to above 15 (where c and a, respectively, are terms that determine the amount of shear). In addition, the method 300 may be applied to the rendering of sheared bitmaps where row sequential or column sequential output band rendering results in reading of source tiles in a column sequential manner. Such occurs in cases (1) and (3), referred to above. For such sheared bitmaps, source pixel fragments of limited size are required to render any given output 20 band. For such sheared bitmaps, the cache buffer for the bitmap 305 may store more than two (2) or three (3) rows or columns of source tiles, as described above for the methods 200 and 300. However, the size of the cache buffer for the bitmap 305 may still be less than the size of the full source bitmap 305. Fig. 4a shows a sheared bitmap 400 where row sequential output band rendering 25 results in reading source tiles in a row sequential manner as per case (2) above. As seen in Fig. 4a, all output bands S-0 through S-4 map to no more than two consecutive rows of source tiles. Therefore source pixel fragments of two source tile rows, comprising ten (10) tiles, may be used to render any output band for the sheared bitmap 400 shown in Fig. 4a. The size of the cache buffer (e.g., configured within cache memory 1048) required to 30 store two source tile rows is less than the size of the full bitmap 400. For example, to render output band S-3, row one (1) and row two (2) source tiles, comprising tiles t5 through t14, are stored within the cache buffer for the bitmap 400. A cache buffer comprising source tiles arranged in rows as described in relation to the method 200 may be used in row sequential output band rendering for rendering the bitmap 400. ^Ann Q3007 Final - 26 Fig. 4b shows a sheared bitmap 401 where row sequential output band rendering results in reading source tiles in a column sequential manner, as per case (3) referred to hereinbefore. As shown in Fig. 4b, all of the output bands S-0 through S-5 map to no 5 more than two consecutive columns of source tiles. Source pixel fragments of two source tile columns, comprising six (6) tiles, may be used to render any output band for the sheared bitmap 401 shown in Fig. 4b. The size of a cache buffer required to store two source tile columns for the bitmap 401 is less than the size of the full bitmap 401. For example, to render output band S-3, column two (2) and column three (3) of source tiles, 10 comprising source tiles t2, t7, t12, t3, t8 and t13, are required. A cache buffer of source tiles arranged in columns as described in relation to the method 300 may be used in a row sequential output band rendering for rendering the bitmap 401. A method 500 of creating a table of bitmap extents, will now be described with reference to Figs. 5a to 5d. The method 500 may be implemented as one or more code 15 modules of the software application program 1033 resident on the hard disk drive 1010 and being controlled in its execution by the processor 1005. The extents table may be configured within memory 1006. In the method 500, output bands are generated in row sequential order using a source bitmap whose inverse affine transform has any generic matrix coefficients a, b, c 20 and d as shown in Eqn. 2. The method 500 may be used for any scaling and/or shearing of the source bitmap with any rotation. In such a case, the rendering of a single output band may require access to a set of source tiles that do not form a source bitmap rows or columns. Fig. 5a shows the mapping of a source bitmap 507 (or "bitmap object") to an 25 output image. The source bitmap 507 comprises twenty four (24) source tile (or bitmap portions) marked TO to T23, arranged in four (4) rows of six (6) columns. The bitmap 507 is mapped to the output image in such way that the output bands marked with S-0 through S-8 are intersected by the source bitmap 507. Output band boundary scan lines are marked with dashed lines 501-504. The first band intersecting the source bitmap 507 is 30 band S-0, bounded by scan lines 501 and 502. Just before the start of rendering output band S-0, source pixels of bitmap 507 need to be available for rendering, so the bitmap 507 needs to be brought to a cache buffer configured within cache memory 1048. The last band intersecting the source bitmap 507 is band S-8, bounded by scan lines 503 and 504. Just after the end of rendering the output band S-8, source pixels of bitmap 507 do not -1 910097 Final -27 need to be available for rendering, so the source pixels may be released or the cache memory 1048 occupied by pixels of bitmap 507 may be reused for other purposes. While rendering any of the output bands S-0 through to S-8, certain sets of 5 source tiles need to be available for rendering. Each of the sets of source tiles (or bitmap portions) may be determined by analysing the affine transform of the source bitmap 507. For example, to render band S-5, bounded by scan lines 505 and 506, the set of source tiles required includes source tiles T6, T7, T12, T13, T14, T15, T16, T21 T22 and T23, marked in Fig. 5a with a cross-hatched pattern. The source tiles T6, T7, T12, T13, T14, 10 T15, T16, T21 T22 and T23 included in the set are the source tiles that intersect the band S-5, wholly or partially. Some of the source tiles T6, T7, T12, T13, T14, T15, T16, T21 T22 and T23, for example source tiles T12, T13, T21, also intersect output band S-6, so the source tiles T12, T13 and T21 need to remain in the cache buffer for bitmap 507, when rendering moves to the output band S-6. Some of the source tiles from set of source 15 tiles T6, T7, T12, T13, T14, T15, T16, T21 T22 and T23, for example source tiles T7, T16 are no longer needed when rendering finishes the output band S-5. The cache memory 1048 occupied by source tiles T7, T16 may be reused for other purposes when rendering of the output band S-5 finishes. By analysing the affine transform of the source bitmap 507, the set of output 20 bands intersected by a given source tile (or bitmap portion) may be determined. The set of output bands intersected by the source tile determines when the source tile needs to be available for rendering, and when the source tile is no longer needed. As described above, the set of output bands for which the given source tile needs to be available for rendering, is called the "bitmap tile extents". For example, tile T2 of Fig. 5a intersects bands S-1, S 25 2 and S-3. Therefore, the bitmap extents of tile T2 in Fig. 5a are bands S-1 to S-3. The table of Fig. 5b lists the boundaries of bitmap extents of the bitmap 507. The table of Fig. 5b is a list of the extents of the source tiles (or bitmap portions) of the bitmap 507. The method 500 may be used for creating the list of extents (i.e., the table of Fig. 5b) of the source tiles (or bitmap portions), as described below. Each line in the table of 30 Fig 5b shows the sets of source tiles starting and ending on the given output band. The table of Fig. 5b comprises four columns as follows: 0 Output Band column: indicating band number; * Tiles needed column: indicating Output Band is the start extent of each source tile in the list of tiles, Tiles, needed. For example, source tile numbers four 35 (4) and five (5) have start extent SO, as indicated by the presence of the numbers anACZnI 930087 Final -28 four (4) and five (5) in the list 512 at the first row of the table of Fig. 5b where output band is SO; e Tiles ending column: indicating Output Band is the end extent of each 5 source tile in the list of tiles, Tiles, ending. For example, source tile numbers eighteen (18) and nineteen 19 have end extent S8, as indicated by the presence of the numbers 18 and 19 in the list 515 at the last row of the table where output band is S8, and " Tiles in the cache buffer column: which will be described in more detail 10 below. The table of Fig. 5b is sorted by output band numbers. For example, the second line in the table of Fig. 5b specifies that the output band SI marks the start of source tiles T2, T3 and T 11 extents, and end of source tile T5 extents. The end extents 510 at band SO 15 does not exist, because bitmap data is starting at band SO. The value "-1" indicates that there are no extents ending at band SO. The start extents 520 at band S8 does not exist, because bitmap data is ending at band S8. The value "-2" indicates that there are no extents starting at band S8. . The method 500 begins at determining step 540, where the processor 1005 20 determines a vertical component, rowheight, in output band units of a vertical side of a source tile after mapping by the formula in Eqn. 1. The vertical component, row-height, is determined by multiplying coefficient D of the affine transform of bitmap 507 by height of a source tile or "minimal coding unit"_(i.e., row-height = D * MCU width). Also at step 540, the processor 1005 determines a 25 vertical component, skewheight, in output band units of a horizontal side of a source tile after mapping by Eqn. 1. The vertical component, skewheight, is determined by multiplying coefficient B of the affine transform of bitmap 507 by the height of a source tile (or minimal coding unit) (i.e., rowskew = B * MCU width). A vertical component, margin-height, in output band units of a vertical 30 margin between two source tiles is also determined at step 540. The vertical component, marginheight, is determined by multiplying coefficient D of the affine transform of bitmap 507 by number (i.e., ipixels) of overlapping pixels needed (i.e., margin-height = D * ipixels). Also at step 540, the processor 1005 determines, a vertical component, margin-skew, in output band units of a nO -1930087 Final -29 horizontal margin between two source tiles. The vertical component, margin-skew, is determined by multiplying the coefficient B of the affine transform of the bitmap 507 by the number (i.e., ipixels) of overlapping pixels 5 needed (i.e., margin-skew = B * i-pixels). Tile overlap is needed for output interpolation. When rendering pixels mapping to points near the border of a source tile (or bitmap portion), pixels from the neighbouring minimal coding unit may be needed. In the case of classic nearest neighbour linear 10 interpolation, a single pixel is needed, in which case ipixels = 1. The sum of row height and skew-height determines the extent of a mapped source tile of the bitmap 507. At extent determining step 542, the processor 1005 determines scan line extents (i.e., Yrowstart and Yrowend) of the first source tile of the first row such as tile TO of bitmap 507 (i.e., (Yrowstart,Yrowend) = determine TO extents). The scan line extents, 15 Yrowstart, Yrowend, are determined by adding the values "row-height plus marginheight" and "row_skew plus marginskew", respectively, to translation term t from Eqn. 1. Then at initialising step 545, the processor 1005 initializes a counter R for iterating over rows of the bitmap 507 and also initializes a current source tile number, tile 20 (i.e., R = 0; tile = 0. The following steps 547 through 590 iterate over all bitmap rows. At initialising step 547, the processor 1005 initializes scan line extents Ystart and Yend of a first source tile in a first row, such as source tiles TO, T6, T12 and T18 in Fig. 5a, that will be used to determine the bitmap extents of source tiles processed in a first iteration of the method 500 (i.e.., (Ystart,Yend) = (Yrowstart,Yrowend)). At counter initialising step 25 550, the processor 1005 initializes a counter C for iterating over columns in a row of the bitmap. Steps 552 through 577 iterate over all bitmap columns. Steps 552 through 570 perform the updating of the sets of source tile extents in the extent table, configured within memory 1006, with the extents of the source tile. At determining steps 552 and 555, the start and end output bands corresponding to the scan 30 lines Ystart and Yend respectively, are determined by the processor 1005 (i.e., startband = determine band(Ystart), endband = determine band(Yend)) by dividing respective scan line by output band height. Then at decision step 557, if the processor 1005 determines that the entry in the extents table for band startband already exists, then the method 500 proceeds to step 560. Otherwise, the method 500 proceeds to step 562. 930087 Final - 30 At tile adding step 560, the processor 1005 adds the current source tile to a list of source tiles starting at band number startband (i.e., ADDSTARTTILE(startband, tile)). Otherwise, at entry adding step 562, the processor 1005 adds an entry with band 5 number startband to the extents table configured within memory 1006 and initializes the list of source tiles starting at band number startband to a single element, namely, the current source tile (i.e., ADDROW(startband, tile, -1)). The list of source tiles ending at startband band is initialized to the empty list, as indicated by a value of "-I" in the table of Fig. 5b. The value "-1" is stored to indicate absence of a value for the ending extent. 10 For example 510 in the first row of the table of Fig. 5b has the value "-I" as ending extent. The method 500 then proceeds to decision step 565, where if the processor 1005 determines that the entry in the extents table for band endband exists, then the method 500 proceeds to step 567. Otherwise, the method 500 proceeds to step 570. At tile 15 adding step 567, the processor 1005 adds the current source tile to the list of source tiles ending at band number endband (ADD_ENDTILE(end band, tile)). Otherwise, at entry adding step 570, the processor 1005 adds an entry with band number, endband, to the extent table configured within memory 1006 and initializes the list of source tiles ending at band number endband to a single element, namely, the current source tile (i.e., 20 ADDROW(end band, -1, tile)). The list of source tiles starting at band number endband is initialized to an empty list, as indicated by a value of "-1". The value "-1" is stored to indicate the absence of a value for the starting extent. Steps 567 and 570 conclude the process of updating the lists of source tile extents to take into account the current source tile. For example, in case of source tile T2 of bitmap 507, at steps 552 and 25 555, the processor 1005 determines startband and endband to be S1 and S3, respectively. Therefore, subsequently, at entry adding step 562, the processor 1005 adds the entry for band S1 to the table of 5b, initializing the list of source tiles starting at band S1 to source tile number two (2). The list of source tiles starting at band S1 will be extended to include source tile numbers three (3) and eleven (11) in later iterations. Then, 30 subsequently, at step 567, the processor 1005 updates the list of source tiles ending band S3 by adding source tile number two (2) to the list. Step 567 is executed because the entry for band S3 already exist in the table of 5b: entry for band S3 is created while source tile T1 has been processing and source tile number one (1) was added to the list of source tiles ending at band S3. The list of source tiles ending at band S3 will be extended to 35 include tile numbers ten (10) and eleven (11) in later iterations. - -0 R7 Finnl -31 The method 500 continues at adding step 572, where the processor 1005 performs the addition of rowskew to each of the scanline extents Ystart and Yend (i.e., (Ystart,Yend) += (rowskew, rowskew)). With the addition of rowskew, Ystart and 5 Yend are adjusted to indicate the scan line extents of the next source tile in row R and column C+1. Next, at decision step 575. if the processor 1005 determines that all source tiles in the current row have been processed (i.e.., C < bitmap columns), then the method 500 proceeds to step 580. Otherwise, the method 500 proceeds to step 577. At counter updating step 577, the column counter C is updated to the next 10 column and the source tile counter, tile, is updated to the next source tile (i.e., C=C+1, tile = tile + 1), the next source tile is examined and execution returns back to step 552. At value adding step 580, the processor 1005 adds the value of rowheight to each of the scan line extents Yrowstart and Yrowend. With the addition of row-height, Yrowstart and Yrowend are adjusted by the processor 1005 to indicate the scan line extents of the 15 first source tile in the next row of the bitmap. For example, after having finished the execution of the iteration 552 through 577 for row zero (0) source tiles TO through T5 of bitmap 507, Yrowstart and Yrowend still contain the scan line extents of source tile TO. After the step 580 adjustment, Yrowstart and Yrowend contain the scan line extents of source tile T6. 20 Next, at decision step 585, if the processor 1005 determines that all the rows and source tiles in the bitmaps (or bitmap objects) have been processed (i.e., R < bitmap rows), then the method 500 proceeds to step 590. Otherwise, the method 500 proceeds to step 595. At row updating step 590, the row R is updated to the next row of source tiles (i.e., R=R+1) and the method 500 returns to step 547. At value changing step 595, the 25 processor 1005 changes the value of the starting extent set in the last row of the extents table, such as the row 520 in the table of Fig. 5b, from -1 to -2. For a bitmap subject to any affine transform, that cannot be rendered in accordance with the methods 200 and 300, the last row of the bitmap extent table contains an empty list of starting source tiles. Therefore, the empty list is indicated by the value of -1 which is changed to -2 at step 30 595 to indicate the end of bitmap extents. The last column of the table of Fig. 5b shows the number of source tiles active at a given time, which is the number of source tiles required to be in the cache buffer for the buffer 507 configured within cache memory 1048. The number of source tiles active at a given time is determined as the total number of source tiles started in the table up to and ^A --- -IQ300OR7 Final -32 including current row, minus total number of source tiles ended in the table in previous rows, according to the Equation (5), below: n n-I C(n) start(i) - E end(i) = C(n -1) + start(n) - end(n -1), Eqn. 5 i=0 i=0 5 where C(n) is the number of source tiles in the cache buffer of nth row, start(n) is the number of source tiles in the list of source tiles needed column of nth row, and end(n) is the number of source tiles in the list of source tiles ending column of 10 nth row. For example, in the fourth row of the table of Fig. 5b, which corresponds to output band S3, there are ten source tiles in the cache buffer for the bitmap 507, two source tiles more than in the third row, which corresponds to output band S2, in which 15 there are eight source tiles. Four source tiles had started in the fourth row (i.e., tiles 7,8,16,17), and two tiles had ended in the third row (i.e., tiles 3, 4). Eqn. 5 may be used to determine the number of source tiles required in the cache buffer for all rows of the table of Fig. 5b. Following the rendering of band S-8, there should be no source tiles left in the cache buffer configured within the cache memory 1048 for the bitmap 507. 20 From the data in the table of Fig. 5b, it can be determined that the maximum number of source tiles needed for rendering the bitmap 507 is eleven (11), which occurs in the last column, i.e., while rendering output band S-4. Therefore the size of the cache buffer for the bitmap 507, configured within cache memory 1048, required to hold the data for the source bitmap 507 for rendering is eleven (11) source tiles, which is less than 25 the size of the full bitmap 507. Memory organization of the cache buffer for source tiles of the bitmap 507 as well as the sequence of fetching the data for the source bitmap 507 into the cache buffer, while rendering the output bands, will now described with reference to Fig. Sc. Since the size of the cache buffer for the bitmap 507 (i.e., eleven (11) source tiles) is smaller than 30 the overall size of the bitmap 507 (i.e., twenty four (24) source tiles) some of the source bitmap data overwrites the existing bitmap data during rendering. The cache buffer for the bitmap 507 is organized in pixel row sequential order so as to aid quick access to a source bitmap pixel, given a particular output pixel. A portion of the cache memory 1048 comprising the cache buffer for the bitmap 507 is divided into eleven (11) blocks, such as ' ArZAAO.. 930087 Final - 33 block 535, marked c0 through c10. Each block of memory is capable of holding the pixels of a single source tile. The blocks of memory that are not used to hold the source pixels are organised into free list 537 using any suitable free list memory organisation method. 5 An array of 6x4 pointers 530, each pointer corresponding to one source tile, is maintained within memory 1006 to point to the blocks that hold the pixels. Those pointers that do not point to a valid block of source pixels are set to a null pointer. The method 500 will now be further described by way of example with reference to Fig. 5c. The loading of the cache buffer for the bitmap 507 with appropriate source 10 data at the appropriate time is determined by the data from the table of Fig. 5b. Before rendering the output band SO, two blocks of the memory 1006 are removed from free list 537 and are pointed to by pointers corresponding to source tiles T4 and T5. The respective source tile data is loaded into these two removed blocks of the memory 1006. 15 Before rendering the output band S1, three blocks of the memory 1006 are removed from free list 357 and pointed by pointers corresponding to source tiles T2, T3 and T 11. The respective source tile data is loaded into these three removed blocks of memory 1006. After rendering the output band S1 is complete, the block of the memory 1006 pointed to by pointer corresponding to source tile T5 may be moved back to free list 20 537, as data in the block of the memory 1006 pointed to by the pointer corresponding to source tile T5 is no longer needed. Before rendering the output band S2, four blocks of the memory 1006 are removed from free list 537 and pointed by pointers corresponding to source tiles TO TI, T9 and TI0. The respective source tile data is loaded into these four removed blocks of 25 the memory 1006. At this point, the eight (8) blocks of the memory 1006 hold the bitmap data while three (3) blocks of the memory 1006 are in the free list, as shown in Fig. 5c. Eight pointers in array 530 are assigned pointers to blocks of the memory 1006, while all other pointers (e.g., T5 and T6) in the array 530 are set to null pointers. The address A of the source pixel in the cache buffer, configured within cache 30 memory 1048, for the bitmap 507 may be determined based on source pixel coordinates (v, u) of the bitmap 507 in accordance with Equation (6) as follows: A = T[L u ,Lv J] + Wu+ v Eqn. 6 4H 6W where T is the array of pointers as described above, ,~aeIa~ QIh0R7 Finni - 34 H is the height of the source tile in pixels, and W is the width of the source tile in pixels. In the methods 200, 300 and 500 described above, source tiles are decompressed 5 and stored in the cache buffer for the bitmap 507 once only. No copying or shifting of the pixel data in the cache buffer for the bitmap 507 is required. The size of the cache buffer for the bitmap 507 itself may be determined prior to rendering and remains constant throughout the rendering of the whole display list. In the methods 200, 300 and 500, caching of source tiles involves decompression 10 of source tiles and subsequent storing of the uncompressed source tiles in a cache buffer as described above. Variations of the methods 200, 300 and 500 may involve retrieving uncompressed or compressed source tiles from a slower memory device such as the hard disk 1010, or from across the network 1020, and storing the uncompressed source tile in a cache buffer configured within cache memory 1048 as described above. Furthermore, 15 individual pixels within an output band may be rendered in any order. Individual pixels within an output band may, for example, be rendered in a row sequential manner, rendering a top scan line of the band first, and progressing through to a bottom scan line of the band. Within each scan line, pixels may be rendered from left to right, or right to left. Alternatively, individual pixels within an output band may be rendered in a column 20 sequential manner, rendering a rightmost column of pixels first, and progressing through to a leftmost column of pixels in the band. Within each column of pixels, pixels may be rendered from top to bottom, or bottom to top. Fig. 6 shows the tables (or lists) of bitmap extents of bitmaps (or bitmap objects) 205, 305 and 507 as shown in Fig 2b, 3b and first three columns of table 5b respectively, 25 combined into a single table, if bitmaps 205, 305 and 507 are rendered on the same page. The table of Fig. 6 is extended by an extra column (Bitmap) which indicates what bitmap each row applies to. The table of Fig. 6 comprises four columns as follows: " Output Band column, indicating combined first column of individual tables; 30 e Bitmap column, indicates a bitmap. For example, bitmap 205 in the Bitmap column of Fig. 6 identifies the bitmap 205 from Fig. 2a; * Fragments needed column, indicates the combined second column of individual tables. A value in the Fragments needed column may be either row number such as 610 for row 0, column number such as 620 for column 0, or list of source tile 35 numbers such as 630 for source tiles 18 and 19; and --- I Q*IOR'7 Finnil - 35 Fragments ending column, indicates the combined third column of individual tables. A value in the Fragments ending column may be either row number such as 610 for row 0, column number such as 620 for column 0, or a list of source tile 5 numbers such as 630 for tiles eighteen (18) and nineteen (19). The data in the table of Fig. 6 may be used as an overall sequence of steps for loading a combined bitmap cache buffer with appropriate source data at the appropriate time. The table of Fig. 6 is sorted by output band number. By reading entries of the table of Fig. 6 in sequential order, the processor 1005 may decide when to load appropriate 10 fragments (i.e., rows, columns or source tile sets) of appropriate bitmaps into the combined cache buffer, configured within cache memory 1048, whenever appropriate source pixels are required for rendering. The loading of appropriate bitmap fragments was described above. Cache buffers for bitmaps 205, 305 and 507 may be combined into a single cache buffer by concatenating the cache buffers for bitmaps 205, 305 and 507, in 15 which case the size of the combined cache buffer is the sum of individual cache buffer sizes (i.e., eight (8) source tiles of bitmap 205 + twelve (12) tiles of bitmap 305 + eleven (11) tiles of bitmap 507). However, the multiple bitmap combined cache buffers referenced by the table of bitmap extents such as Table 6 may be combined into a single cache buffer which is smaller in size than the sum of the individual cache buffers. The 20 combining of the bitmap cache buffers into a single cache buffer will be described below. An example of multiple bitmap cache buffers being combined into a single cache buffer of size smaller than the sum of individual cache buffers will now be described with reference to Fig. 7a. Page 700 of Fig. 7a is rendered in row sequential order of output bands. For ease of explanation, it is assumed that each of scan lines LO through L6 25 belong to different output bands, so the output lines LO through L6 are rendered in sequential order. Four bitmaps are required to be rendered in the generation of output for Page 700, as follows: - "Bitmap 3" 703 has been rotated by ninety (90) degrees, so the method 300 described above may be used to render Bitmap 3. Rendering Bitmap 3 requires a cache 30 buffer of size able to store three columns of source tiles shown in Fig. 7a as a subset 713 of Bitmap 3. Bitmap 3 extends from scan line LO to scan line LI. - "Bitmap 4" 704 has been mapped without rotation, so the method 200 described above may be used to render Bitmap 4. Rendering Bitmap 4 requires a cache buffer of size able to store four rows of source tiles shown in Fig. 7 as a subset 714 of 35 Bitmap 4. Bitmap 4 extends from scan line LO to scan line L2. O'MOR7 Finnl -36 - "Bitmap 1" 701 has been mapped without rotation, so the method 200 described above may be used to render Bitmap 1. Rendering Bitmap I requires a cache buffer of size able to store five rows of source tiles shown in Fig. 7a as a subset 711 of 5 Bitmap 1. Bitmap 1 extends from scan line L4 to scan line L5. - "Bitmap 2" 702 has been rotated by ninety (90) degrees, so the method 300 described above may be used to render Bitmap 2. Rendering Bitmap 2 requires a cache buffer size able to store five columns of source tiles shown in Fig. 7a as a subset 712 of Bitmap 2. Bitmap 2 extends from scan line L3 to scan line L6. 10 Bitmap 4 extends from scan line LO to scan line L2. Bitmap2 extends from scan line L3 to scan line L6. Therefore, the extents of Bitmap 2 and Bitmap 4 are disjoint. As a result, source pixels of Bitmap 4 are not needed at the same time as source pixels of Bitmap 2 are needed, and vice versa, so cache buffers used for Bitmap 2 and Bitmap 4 may share the same portion of cache memory 1048. 15 Similarly, Bitmap3 extends from scan line LO to scan line LI. Bitmap1 extends from scan line L4 to scan line L5. Therefore, the extents of Bitmap 1 and Bitmap 3 are disjoint. As a result, source pixels of Bitmap 3 are not needed at the same time that source pixels of Bitmap I are needed, and vice versa, so cache buffers used for Bitmap 3 and Bitmap I may share the same portion of memory 1006. 20 Fig. 7b shows an example memory layout of a cache buffer 710 that takes advantage of disjoined bitmap extent sets described in the previous paragraph. The cache for Bitmap 3 and the cache for Bitmap I have been placed at address 720 of the cache buffer 710. The cache of Bitmap 4 and the cache of Bitmap 2 have been placed at the same address 730 of the cache buffer 710. Address 730 is address 720 plus the larger of 25 Bitmap 1 cache size and Bitmap 3 cache size. The arrangement of the bitmap cache buffer 710 results in significant memory savings. Total memory used by the cache buffer 710 is equal to the size of the cache of Bitmap I plus the size of the cache of Bitmap 2, which is significantly less than the sum of all cache buffers for Bitmaps 1, 2, 3 and 4. A method 900 of determining layout of a cache buffer and total size required for 30 the cache buffer will now be described by way of example with reference to Figs. 8a, 8b and 9. The method 900 may be implemented as one or more code modules of the software application program 1033 resident on the hard disk drive 1010 and being controlled in its execution by the processor 1005. In the present example, page 800 as seen in Fig. 8a is rendered in row sequential 35 order of output bands. Page 800 has five bitmaps, which are, in order of starting extents: - I---- - Q02 R7 Finn -37 "Bitmap 3" 803 with extent L3start to L3end, "Bitmap 4" 804 with extent L4start to L4end, "Bitmap 5" 805 with extent L5start to L5end, "Bitmap 1" 801 with extent LI start to Llend, and finally "Bitmap 2" 802 with extent L2start to L2end. 5 For the example of Fig. 8a, scan lines L3start and L4start are the same as shown in Fig. 8b. Similarly, scan lines L3end and L5end are the same. All other scan lines labelled in Fig. 8a are different and furthermore belong to mutually different output bands. If any two scan lines belong to the same output band, then the two scan lines are considered the same for the purpose of the method 900. The method 900 may be used 10 for determining a size of the buffer 870 for storing the plurality of bitmaps 801, 802, 803, 804 and 805 using an extents table (or list of extents), as described below. The method 900 begins at data storing step 910, where the processor 1005 stores data in an extents table configured within memory 1006. In particular, the processor 1005 stores start and end extents for a plurality of bitmap objects in the form of Bitmap 1, Bitmap 2, Bitmap 3, 15 Bitmap 4 and Bitmap 5 of Fig. 8a in the extent table. Each entry of the extents table describes either a start extent or an end extent of a given bitmap, such that each portion of the bitmap has an extent in one direction. Each entry of extent table comprises the following fields: e bitmapID field: a unique number to identify the source bitmap; 20 e extentband field: one of the extents as described in the previous paragraph. At step 910, the processor 1005 takes the values of extentband from a table representing a list of extents, such as the table shown in Fig. 2b, 3b or 5b, as determined by the method 200, 300 or 500, respectively. For example, band SO would be the extentband in the extent table entry describing start extent of 25 bitmap 205 shown in Fig. 2a, and S5 would be the extent-band in the extent table entry describing end extent of bitmap 205, while SO would be the extent-band in the extent table entry describing start extent bitmap 500 shown in Fig. 5a, and S8 would be the extentband in the extent table entry describing end extent of a bitmap 507. 30 e isend field: a Boolean flag indicating the kind of extent in this entry (end extent or start extent); and * size field: a number identifying the size of an individual bitmap cache, configured within memory 1006, as determined by the method 200, 300 or 500. The sizefield may be used for determining a size of an individual bitmap cache I n 1 ZO ()57 Fnnl - 38 within the buffer 870 for storing one of the plurality of bitmap portions, using one of the tables (or lists of extents). 5 Additional data in each entry of the extent table, which stays uninitialized after step 910 and is determined during the course of the rest of the method 900, comprises: * address, the address in the cache buffer 870; and e isleft, a Boolean flag indicating the left or right side of the buffer 10 The total number of entries in the extent table for the example of page 800, is ten and comprises the start extent entry and the end extent entry for each of five bitmaps. Both start extents and end extents of the extent table, are sorted together by the processor 1005 in output band rendering order in sorting step 915. The start extents and end extents are sorted firstly by the band in which an event occurs (extentband) and 15 secondly by whether the event is a start event or end event (is-end). Therefore, if some start extents happen to be in the same band as some end extents, then start extents are placed before end extents. A start extent occurring in a particular output band signifies that a portion of the memory 1048 for caching the corresponding bitmap data will become available in time for processing that band. An appropriate amount of cache memory 1048 20 will be reserved for the bitmap becoming active at the corresponding output band. Conversely, an end extent occurring in a particular output band signifies that the corresponding bitmap becomes inactive at the end of processing that band. The cache memory 1048 reserved for the bitmap may be made available to other bitmaps past the corresponding output band. 25 At initialising step 920, the processor 1005 initialises the values of variables to track current and maximum cache sizes for a left side 871 and right side 872 of cache buffer 870 as seen in Fig. 8b. The cache buffer 870 may be configured within the cache memory 1048. The variables initialised at initialising step 920 include "current left size", "current right size", "max left size" and "max right size". Max left size and max right size 30 represent maxima obtained by current left size and current right size of the buffer 870, respectively. The method 900 continues at examining step 925, where the processor 1005 initializes a loop over the extent table configured within memory 1006 and examines a first entry in the extents table. Steps 930 through 970 loop over the extent table. Each 35 entry in the extent table is either a start extent or an end extent event.

-39 As seen in Fig. 8b, list 860 shows the sequence of start extent and end extent events for page 800. The sequence comprises ten events, each event corresponding to an element of the extent table, elements of the extent table ordered by band number, namely 5 extentband value. The entries of the extent table are processed at steps 930 through 970. At decision step 930, if the processor 1005 determines that the event is a start extent event, by examining the is-end value associated with the event, then the method 900 proceeds to determining step 940. Otherwise, the event is a start extent event and the method 900 proceeds to recording step 945. If the event in the list 860 is a start extent 10 event, as determined at step 930, then the need for an appropriate amount of memory, equal to the size of cache required for the bitmap corresponding to that event, needs to be recorded. At determining step 940, the processor 1005 determines where a portion of the memory 1048 for caching the bitmap corresponding to the event should be reserved. The 15 portion of memory 1048 may be reserved on the left side 871 of the cache buffer 870 (i.e., lowest address available), or on the right side 872 of the cache buffer 870 (i.e., highest address available). If the processor 1005 determines at determining step 940 that the memory 1048 needs to be reserved on the left side 871 of the cache buffer 870, then the method 900 proceeds to step 941. Otherwise, the method 900 proceeds to step 943. Step 20 940 will be described in further detail below. At updating steps 941 and 942, the processor 1005 performs the update of the address field in the extent table, and current left size and max left size variables in case a block of the memory 1048 is reserved to the left of the buffer 870. In particular, at step 941, the processor 1105 records first free address at start of the buffer 870 and marks a 25 plurality of bytes to be reserved, according to the current left size and max left size variables. Then at step 942, the processor 1005 updates the cache size requirements on the left of the buffer 870 by updating the current left size and max left size variables. At updating steps 943 and 944, the processor 1005 performs the update of address field in the extent table, and current right size and max right size variables in case 30 a block of memory 1048 to be reserved to the right of the buffer 870. In particular, at step 943, the processor 1105 records first free address at end of the buffer 870 and marks a plurality of bytes to be reserved according to the current right size and max right size variables. Then at step 944, the processor 1005 updates the cache size requirements on the right of the buffer 870 by updating the current right size and max right size variables. 35 For example, in the case of an event corresponding to the output band of L3start, which -a-n 1 oN007 Final - 40 corresponds to the start of Bitmap 3 extent, the processor 1005 records that the cache for bitmap 803 is needed so a region 813 of the memory 1048 containing the buffer 870 is reserved. In this instance, at decision step 940, the processor 1005 determines that the 5 region 813 should be reserved to the left 871 (lowest address available) of the cache buffer 870, so the region 813 is assigned to the address 830, which is address 0 relative to the start of the cache buffer 870. Each left side 871 portion and right side 872 portion of the buffer 870 may be used for storing portions of the bitmaps 801-805 with non-overlapping extents, as seen in 10 Fig. 8b. For example, portions of Bitmap 3 are stored on the left side 871 of the buffer 870 together with a portion of Bitmap 1. The portions of Bitmap 3 and the portion of Bitmap I have non-overlapping extents. Similarly, portions of Bitmap 4 are stored on the right side 872 of the buffer 870 together with portions of Bitmap 2. The portions of Bitmap 4 and the portions of Bitmap 2 have non-overlapping extents. 15 In the case of the event corresponding to the output band of L4start at step 930, which corresponds to the start of Bitmap 4 extent, at decision step 940 the processor 1005 determines that the region of memory 1048 for bitmap 804 needs to be reserved to the right 872 (highest address available) of the overall cache buffer 870. Then at step 943, the processor 1005 assigns the value minus "Bitmap 4 cache size" to the "address" field of 20 the current extent table entry. In this instance, at final step 980, after "overall cache size" has been determined, the value of the address field will be adjusted to address 850, which is address "overall cache size" minus "Bitmap 4 cache size". Then at step 943 the processor 1005 records the reservation of a region 814 of the memory 1048 as the cache for bitmap 804. Then, at step 944, the processor 1005 updates the "current left size" and 25 "max left size" to be the size of the region 814. In the case of the event corresponding to the output band of L5start at step 930, which corresponds to the start of Bitmap 5 extent, at decision step 940 the processor 1005 determines that the region of memory 1048 for bitmap 804 needs to be reserved to the left 871 (lowest address available) of the overall cache buffer 870 configured within cache 30 memory 1048. In this instance, at step 941, the processor 1005 assigns address 815, which is address "Bitmap 3 cache size" and records the reservation of a region 815 of memory 1048 as a cache for bitmap 805. Then, at step 942, the processor 1005 updates the "current left size" and "max left size" to be the size of buffer 813 plus size of buffer 815. In the case of the event corresponding to the output bands of L5end, L3end and 35 L4end, corresponding to the end of Bitmap 5, Bitmap 3 and Bitmap 4 extents, ZnO 930087 Final -41 respectively, at decision step 930 the method 900 proceeds to recording step 945. At recording step 945, the processor 1005 records that the respective bitmap caches are not needed any more, so the respective regions 815, 813 and 814 are freed from the cache 5 buffer 870. In particular, the processor 1005 removes the record of reserved "size" bytes in the buffer 870. Then, at step 950, the processor 1005 updates the variables "current left size" and "current right size" to reflect the change in the size of the reserved memory in the left side 871 and right side 872 of the buffer 870 respectively. At the conclusion of processing Bitmap 4 extents, the cache buffer 870 is empty. Therefore both "current left 10 size" and "current right size" are set to zero. In the case of the event corresponding to the output band of L2start at step 930, which corresponds to the start of Bitmap 2 extent, at decision step 940, the processor 1005 determines that the region of memory 1048 for bitmap 802 needs to be reserved to the right 872 (highest address available) of the cache buffer 870. In this instance, at step 15 943, the processor 1005 assigns the value minus "Bitmap 2 cache size" to the "address" field of the current extent table entry. Also, in this instance, at final step 980, after "overall cache size" has been determined, the value of the address field will be adjusted to the address 840, which is the address "overall cache size" minus "Bitmap 2 cache size". Then at step 943, the processor 1005 records the reservation of a region 812 of the 20 memory 1048 as the cache for bitmap 802. Then, at step 944 the processor 1005 updates "current left size" and "max left size" to be the size of buffer 812. After the processing of each event in the extent table, at decision step 960, if the processor 1005 determines that there are more elements remaining in the extent table, then the method 900 returns to step 970. At step 970, the processor 1005 iterates to the 25 next element of the extent table and the method 900 loops back to step 930. Otherwise, after all entries in the extent table, configured within memory 1006, have been examined, then the method 900 proceeds to determining step 980. After all of the events in the list 860 have been processed, at step 980, total (or maximum) cache sizes of the left part 871 and the right part 872 of the cache buffer 870 30 are determined by the processor 1005 as the sum of max right size and max left size variables. Values determined at step 980 may be stored in the memory 1006. In the example of buffer 870, the maximum left size 871 was determined by the LIstart event, and is equal to the size of Bitmap 1 cache 811, while the maximum right size 872 was determined by the L2start event, and is equal to the size of Bitmap 2 cache 812. The size 35 of overall cache buffer 870 is determined as the sum of the maximum left size and Q'.-0R'7 Finnl -42 maximum right size, and the left side is concatenated with the right side along the boundary 820. Finally, with the size of the buffer 870 being known, the addresses of bitmap cache buffers 814 and 812 reserved to the right 872 of the buffer 870 are 5 determined as part of step 980. In the example of Figs. 8a and 8b, the reserved cache buffers to the left 871 of the buffer 870 may then be used for storing the portions of Bitmaps 1, 3 and 5, as shown in Fig. 8b. Further, the reserved cache buffers 814 and 812 may then be used for storing the portions of Bitmaps 2 and 4, as shown in Fig. 8b. Several heuristics may be used in step 940 to determine whether a given region 10 should be reserved to the left 871 or to the right 872 of the cache buffer 870. In one implementation, at step 940, the processor 1005 chooses the side of the cache buffer 870 which results in the least growth of the sum of the left and right maximum sizes. Furthermore, regions may be distributed within the cache buffer 870 or within the sides 871 and 872, not necessarily to the minimum left and to the maximum right only, as 15 implemented in steps 941 to 944. Also, the size and extents of the participating caches may determine their distribution, subject to step 940. For example, smaller caches or caches occupying smaller extents may be favoured to be placed to the left of the buffer 870 while larger caches or caches occupying larger extents to be placed to the right of the buffer 870. Other distributions methods may also be applied. 20 A method 1100 of storing a plurality of bitmap objects in a cache buffer will now be described with reference to Fig. 11. The method 1100 may be implemented as one or more code modules of the software application 1033 resident on the hard disk drive 1010 and being controlled in its execution by the processor 1005. The method 1100 begins at defining step 1101, where the processor 1005 25 performs the step of defining a plurality of bitmap portions for the plurality of bitmap objects. For example, as described above, a plurality of source tiles (or bitmap portions) are defined for each of the bitmap objects in the form of the bitmaps 205, 305 and 507. Each of the bitmap portions (or source tiles) defined for the bitmaps 205, 305 and 507 have a start extent and end extent in one dimension. For example, the source tiles tO, 30 tl, t2 and t3 of bitmap 205 each have a start extent in the form of band S-0 and an end extent in the form of band S-2 in a horizontal dimension. At list creating step 1103, the processor 1005 performs the step of creating a list of the extents of the bitmap portions (or source tiles). For example, as described above, the tables of Fig. 2b, 3b and 5b list the boundaries of bitmap extents for the bitmaps 205, 305 35 and 507, respectively. 0Q300R7 Final -43 Then at size determining step 1105, the processor 1005 performs the step of determining a size of the cache buffer for storing one of the plurality of bitmap portions (or source tiles) and the address within said cache buffer where each bitmap portion 5 should be stored, using the list of extents (or table of extents). For example, the method 900 may be used for determining a size required for the cache buffer. As described above, the example extents table of Fig. 8b is used in determining the size of the cache buffer 870. Further, a portion of the cache buffer 870 stores bitmap portions with non overlapping extents. As described above, the example Bitmap 3 of Fig. 8a is stored on 10 the left side 871 of the buffer 870 at address 830, together with a portion of Bitmap 1. The portions of Bitmap 3 and the portions of Bitmap I have non-overlapping extents. With reference to Fig. 7b again, as bitmap portions from Bitmap 3 and Bitmap 4 have overlapping extends, which means bitmap portions from these two bitmap objects are to be rendered on the same rendering bands, the bitmap portions are stored at different 15 addresses in the cache. However, once Bitmap 3 and Bitmap 4 are rendered, the processor 1005 stores the bitmap portions of Bitmap I at a substantially similar address to that of Bitmap 3, in one. The storing of the bitmap portions from Bitmap 1 is implemented based on the extents table, which indicates that the extents bitmap portions from Bitmap 3 have ended, as well as the address information where bitmap portions from Bitmap 3 are 20 stored. Similarly, as the bitmap portions from Bitmap 4 and Bitmap 2 are known to not be rendered in the same rendering bands, bitmap portions from Bitmap 2 will overwrite the buffer portions that used to store bitmap portions from Bitmap 4. The method 1100 concludes at storing step 1107, where the processor 1005 performs the allocation of the buffer 870 based on the size determined in the method 900 25 and the step of storing the plurality of bitmap objects in the buffer, based on the list or extents table. As described above with reference to the example of Figs. 8a and 8b, portions of the bitmaps (or bitmap objects) (e.g., portions of the bitmap 803) are stored in the cache buffer 870. Industrial Applicability 30 It is apparent from the foregoing that the arrangements described are applicable to the computer and data processing industries. The foregoing describes only a limited number of embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not 35 restrictive. -- A 930087 Final -44 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 5 correspondingly varied meanings. Ann 1930087 Final

Claims (10)

1. A method of determining a size of a buffer for storing a plurality of bitmap 5 objects, said method comprising: defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; creating a list of the extents of the bitmap portions; and determining a size of the buffer for storing the plurality of bitmap portions using 10 said list, wherein a portion of the buffer stores bitmap portions with non-overlapping extents.

2. The method according to claim 1, wherein the extent of the bitmap portion is a range of rendering bands during which the bitmap portion is to be available for rendering. 15

3. The method according to claim 2, said method further comprising: storing a first bitmap portion at an address in the buffer, based on the list of extents; and storing at least a second bitmap portion at said address, once the list of extents 20 indicates that an extent of the first bitmap portion has ended.

4. The method according to claim 1, further comprising: defining a plurality of output bands for a page to be rendered; determining, for each of the plurality of bitmap portions, at least one of the 25 plurality of output bands intersected by said each bitmap portion, wherein said creating step creates a list of extents ordered by the rendering order of the plurality of output bands.

5. A method according to claim 2, further comprising analysing the affine transform 30 of the bitmap objects.

6. A method according to claim 1 or claim 2, wherein the size of the buffer is dependent upon a maximum memory requirement of bitmap portions to be rendered for one of the plurality of output bands. 35 - 46

7. A system for determining a size of a buffer for storing a plurality of bitmap objects, said system comprising: a memory for storing data and a computer program; 5 a processor coupled to said memory for executing said computer program, said computer program comprising instructions for: defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; creating a list of the extents of the bitmap portions; and 10 determining a size of the buffer for storing the plurality of bitmap portions using said list, wherein a portion of the buffer stores bitmap portions with non-overlapping extents.

8. An apparatus for determining a size of a buffer for storing a plurality of bitmap 15 objects, said apparatus comprising: means for defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; means for creating a list of the extents of the bitmap portions; and means for determining a size of the buffer for storing the plurality of bitmap 20 portions using said list, wherein a portion of the buffer stores bitmap portions with non overlapping extents.

9. A computer readable medium comprising a computer program stored thereon for determining a size of a buffer for storing a plurality of bitmap objects, said program 25 comprising: code for defining a plurality of bitmap portions for the plurality of bitmap objects, each bitmap portion having an extent in one dimension; code for creating a list of the extents of the bitmap portions; and code for determining a size of the buffer for storing the plurality of bitmap 30 portions using said list, wherein a portion of the buffer stores bitmap portions with non overlapping extents.

10. A method of determining a size of a buffer for storing a plurality of bitmap objects, said method being substantially as herein described with reference to any one of 35 the embodiments as that embodiment is shown in the accompanying drawings. ')A CAMQ-1 012M0'7 17nl - 47 DATED this Twenty Third Day of December 2009 CANON KABUSHIKI KAISHA 5 Patent Attorneys for the Applicant SPRUSON&FERGUSON