[gs-devel] Page (clist) queuing -- Seperate Rendering thread(s)

[Ray Johnston]

All,

The below was sent to 'Tech' back in May. Henry suggested
that this be posted to gs-devel to possibly get more dicussion
going.

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 
universal
way than the old 'gdevprna + gdevbmpa' technique...

Background:

In general, this is based on the 'save page' functionality that Peter 
implemented for
CalComp circa 1997 that was applied to a very feature rich RIP that used 
saved
pages (on disk) to support separate writer(parser) and reader(renderer) 
threads
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 
machine
    was compatible with the requested parameters (media type, width, 
length, ink
    type)

- Imposition: nesting small pages across a larger web, provided all of 
those pages
    had compatible "properties" where the properties included things 
like media
    type (7 types), ink type (dye or pigment), resolution (360/720), 
quality mode
    (draft, normal, best)

- Operator Priority Selection. Pages could be processed out of order if 
an local
    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 
first
    print.

- 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 
names
were part of the information in the saved page structure.

-------------------

Going forward:

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 
selecting pages
    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"..