The concept in bug 691607 can be similarly implemented when using the clist
with devices designed to optimize rendering to halftoned (CMYK) devices such
as the wtsimdi (or a later, better implementations).

We know that often there are large areas of the page that can be painted
without needing non-idempotent ROP effects. If the ROP is idempotent,
then the object could be painted using the methods to paint halftoned data
directly to the non-contone buffer (e.g. CMYK). This will also reduce the amount of memory needed for the contone buffer, and reduce the area that we
then have to perform color conversion on in the raster domain (RBG contone ->
CMYK contone, then halftone). The smaller the area we have to do this with,
the faster a non-ASIC color PCL printer can be.

The problem is that ordinarily we don't know what area can be painted directly
to halftoned CMYK an what area must be painted into the RGB (or RGBtag) 
contone buffers (other than the band by band 'complexity' data we now
collect during clist writing.

When we are using the 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 for non-idempotent
ROPs during playback, then we can use this information during clist_reading
to allow the rendering devices to constrain the bbox of the contone buffer.

The clist playback would then render objects using the halftone buffer if the
object is outside the ROP bbox, or only to the contone buffer if it is entirely
in the ROP 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 contone buffer is color converted and written
to the halftone buffer needed by the device.

For pages that only have a small area affected by non-idempotent ROPs, this can
speed things up, and may reduce the memory because the full width won't be
needed for the contone buffer in bands that do have some difficult ROP
operation.

In order to implement this, we might want to make a ROP_compositor device
that more closely mirrors the pdf14 compositor device to 'normalize' the
way we handle this selective playback from the clist.