Ghostscript CUPS device lacks multi-threading

[ValdikSS]

Creating issue here for visibility.

Ghostscript has multi-threaded rendering of pages (-dNumRenderingThreads=X), as well as separate background writing thread for each of the page when the pages are saved to separate files and not piped over the file descriptor (-dBGPrint=true, at least that's what I think it does).

CUPS device (-sDEVICE=cups) does not support either of these functions because it uses gdev_prn_output_page instead of gdev_prn_BG_output_page, limiting it only to a single thread, page-after-page processing.

There was an attempt to modernize CUPS source but it was reverted back to using gdev_prn_output_page. The details could be found in this bug: https://bugs.ghostscript.com/show_bug.cgi?id=694280

YUCK. The cups device may never support background printing.

It is definitely some of the ugliest code I've seen. It uses a static
_cups_raster_error_t struct, mallocs strings for it, and then never frees them
(#if HAVE_PTHREAD_H is 0)

So far, I've determined that the 'stream' allocation is the reason for 4 extra
bytes (it writes CUPS_RASTER_SYNC at the start of the output). Note that if the
file changes, as with out-%d.cups the files after the first don't have this
SYNC sequence. Definitely a shortcoming.

The writing using the stream uses the fd number, but the file attached to this fileno may no longer be the same file if the %d is used, or if OutputFile is
changed. In fact, it's only "luck" that the same fileno is used over and over.
Not a characteristic I would count on with fclose..fopen.

This 'stream' needs to be passed from instance to instance of the background
printing thread devices - or we need to retain and re-use the device once
it is created (as we do with the semaphore). This will need some thought.

I've patched it to use gdev_prn_BG_output_page and it works fine with -dBGPrint=false (disabled) and multi-threading enabled. It's much faster, each thread brings about 90% of additional performance.
I'm not completely sure I understand what -dBGPrint does, but if I do, CUPS device when using via CUPS basically never saves pages to separate files, so this bug is irrelevant.