It occurred to me that often there are large areas of the page that can be
painted without needing transparency effects. If the alpha == 1.0 and the
BM (blend mode) is Normal, then the object could be painted using the
device methods directly to the device's buffer.

The problem is that ordinarily we don't know what area can be painted this
way and what area must be painted into the buffers of the pdf14 transparency
stack (bottom most level).

When we are using the pdf14_clist devices, however, we aren't actually doing
any painting -- operations are simply going into the clist. If this device
collects a 'bbox' of the area actually needed to be handled by the pdf14
device during playback, then we can use this information during clist_reading
to allow the pdf14 rendering devices to constrain the bbox of the page level
(bottom most, and always largest) transparency stack buffer.

The pdf14_clist playback _would_ then render objects using the target device
if the object is outside the page level transparency bbox, or only to the
transparency device if it is entirely in the page level bbox, or to _BOTH_
if it overlaps. It won't hurt if the objects that cover both areas are
painted into target device's buffer since these 'marks' will be painted over
when the pdf14 device does the 'put_image' of the page level buffer onto
the device.

For pages that only have a small area affected by transparency, this can
speed things up, and may reduce the memory because the full width won't be
needed for the page level transparency buffer in bands that do have some
transparency operation.

An alternative to this that would not rely on the clist device would be
to allocate the page level buffer 'as needed' when painting with alpha < 1.0
or the BM != Normal, performing a 'get_bits_rectangle' for the data that
has already been painted to the target device's buffer, mapping the colors
back to the appropriate default blend cs (e.g., Gray, RGB, CMYK, etc.).

The trouble with this is that the 'get_bits' for some devices is not very
fast also every time we paint outside our previous page level transparency
buffer with an operation that also needs the page level buffer, we need to
get a new, larger, buffer and fill it with data from the old transparency
buffer and the additional area from the target device's buffer. Might work,
but may not provide as much optimization.

If we are using the clist device, I think using the bbox collected initially
might still be best, although a 'hybrid' approach would be to allow the
clist playback to paint to the target device's buffer up to the point
where a transparency operation needed the buffer, then allocate the page
level buffer (using the bbox info collected during clist writing), and
initializing that buffer with the data from the target device's buffer.
This only provides optimization if the target device's painting is enough
faster than the pdf14 device painting to allow for the 'initialization'
overhead of getting the target device's data into the pdf14 transparency
buffer. If we switch the pdf14 device painting over to using chunky pixels
instead of planar bands, this is not likely.