[gs-devel] Page (clist) queuing -- Seperate Rendering thread(s)
Ray.Johnston at Artifex.com
Thu Nov 1 12:50:18 PDT 2007
The below was sent to 'Tech' back in May. Henry suggested
that this be posted to gs-devel to possibly get more dicussion
This _was_ attached in my previous posting (it's that way in my
"Sent" folder), but it didn't make it here. Trying again with the
previous contents simply pasted in...
Some notes on implementing 'async rendering' in a more convenient and
way than the old 'gdevprna + gdevbmpa' technique...
In general, this is based on the 'save page' functionality that Peter
CalComp circa 1997 that was applied to a very feature rich RIP that used
pages (on disk) to support separate writer(parser) and reader(renderer)
on a RTOS that did _not_ have processes with separate memory spaces -- the
OS 'tasks' were essentially threads. The features included:
- Scheduling: Pages would be selected from the queue if the media in the
was compatible with the requested parameters (media type, width,
- Imposition: nesting small pages across a larger web, provided all of
had compatible "properties" where the properties included things
type (7 types), ink type (dye or pigment), resolution (360/720),
(draft, normal, best)
- Operator Priority Selection. Pages could be processed out of order if
or web based operator identified a "priority" job/page.
- Reprint N: Since this was a disk based RIP, pages/jobs were retained and
could be reprinted "N" times by an operator after examination of the
- Collation of copies from jobs with multiple pages.
The key to this functionality was the "saved page" that was a serialized
(text) form structure that retained the information about the page(s) and
jobs. This was serialized to a text file so that it could be written to disk
(non-volatile in the case of power failure). The clist "c" and "b" file
were part of the information in the saved page structure.
These concepts can be extended to any "page" device managed by gdevprn
and to memory based clist (BAND_LIST_STORAGE=memory) modes.
The design goals for the more general implementation are:
- Easy to add to any clist capable device
- Provide a framework queue that can be memory or disk based ( with
an example implementation that has the basic functionality
corresponding to the gdevbmpa device).
- Queue entries (RAM or disk) contain the "pagedevice" parameters that
were in effect at end of page (including PageSize, HWResolution,
NumCopies, ProcessColorModel, ...) that might be usef..ul in
from the queue. We may want to add something for "job" association to
support features like multiple copy collation.
- Queue access that supports "peek" functions (not currently in gxpageq.c)
to access the pagedevice parameters (including wild card _any_ match)
- De-queue _any_ element to allow processing pages out of queuing order
(for nesting/imposition, priority task, ...)
- Queue support for "file" or "memory" (currently only memory) with clist
(BAND_LIST_STORAGE) in either "memory" or "file". Using memory
based clist will require
- A default, simple queue server that processes pages in FIFO order that
works with either the memory or file based queue.
- The simple queue method is a standard runtime action based on a printer
device parameter, e.g. -dQueuePages=true or the PS equivalent:
<< /QueuePages=true >> setpagedevice (PCL and XPS would rely
on the -d method or calling the graphics library).
Please let me know if there are any other features that you think need
to be in the default implementation. Once real embedded customers
start using this, we may find something else they need, but we can
"build that bridge when we come to the creek"..
More information about the gs-devel