(v13) Partial paints
This page applies to Harlequin v13.1r0 and later; and to Harlequin Core but not Harlequin MultiRIP.
It is sometimes the case that there is insufficient memory to hold the whole display list for the page being described. When memory runs out, the RIP tries various strategies to free memory: notably it tries to write images to disk (if there is one). Images can be very large, but can be processed more quickly if they are stored in memory. If there is still not enough memory, the RIP performs a partial paint. This means that the rendering phase is executed prematurely, in the middle of the operation (such as fill, or show) which caused memory to run out, and the page as completed so far is written to disk. The display list is then discarded, and the remainder of the page interpreted. This may cause further partial paints if memory runs out again before the page is complete.
On subsequent rendering (either another partial paint or the final showpage), instead of starting with a white background, the previous page is read back from disk and the new graphics painted on top of it. It is the PostScript-language painting model, where each graphic object is painted opaquely on top of any objects that preceded it, that allows this approach to work.
Because the raster represents dots on the page rather than arbitrary graphic objects, the size of the page is predictable from the size of the raster (except when the raster is run-length-encoded). Thus, providing there is sufficient space on disk to hold a fixed size page at the appropriate resolution, it should be possible to render a page of any complexity, even though it may take a long time. Furthermore, because the page can be delivered from disk to the output device at the end, it should still be possible to drive the device at full speed without data under-run as long as the disk reading speed is not slower than the required data rate of the output engine.
This process is analogous to the frame device model used in low resolution rendering. In that case, however, the partial page buffer is stored in memory rather than on disk, since the memory requirements are feasible at lower resolutions, and often each graphic object is painted into the raster directly rather than going via a display list.
In GUI versions of the RIP, it is possible to compress pagebuffers. This compression helps to reduce the amount of storage needed and the requirement for speed of transfer from that storage.
A number of features of the RIP are incompatible with partial painting notably transparency and some uses of display lists using Harlequin display list technology (the HDLT option).
From Harlequin v14, the recombine feature will be deprecated.