Render separations to frame buffers
(Or just the one if you want).
Introducing IJawsRenderer::renderSeparationsToFrameBuffers()
In essence, this is just a cloned API of renderSeparations(). It departs in just a handful of ways.
The user provides a vector of frame buffer info objects that describe the frame buffers that are to be populated
The user can specify whether they want 16 bit results in host-endian or default (big endian - as used for PDF, PS, etc).
Otherwise, the arguments are the same, and it will behave in the same way, down to producing exactly the same pixel results. The usage, apart from the above (and a reordering of some arguments in order to be safe) is as per renderSeparations().
Argument reordering.
Although renderSeparations() can get away with some arguments having defaults, this API cannot. For example, it’s no longer possible to default width, height or colour space; these must be explicitly specified so that Mako can check that the buffer allocated matches the requirement exactly. As some of the parameters are no longer defaulted, some arguments are reordered compared to renderSeparations() but this should not be too confusing.
The specification of buffers is designed to be as flexible as possible. The user specifies a buffer for each and every separation that will be rendered, up front. The class IJawsRenderer::CFrameBufferInfo provides the description of the buffer. For each CFrameBufferInfo the user specifies:
A pointer to the memory where the first pixel is to be written
A stride describing how many bytes to move in order to get to the next scanline in the buffer
A pixel stride that describes how many bytes to move in order to get to the next pixel in the buffer. This may be 0, in which case the pixels will be packed together with one sample in the separation immediately following the previous in memory.
The pixel stride, if present, must be large enough. That is, it must be larger (in absolute value) than the storage size of a sample. We place no such restriction on the row stride, just in case the user has a creative requirement that needs it . Strides may be negative, allowing upside down or right to left rendering.
This also allows separated results to be written into a single buffer. By allocating single CMYK interleaved buffer for the resulting image, you could configure the CFrameBufferInfo vector such that (8 bit example here):
The Cyan buffer info points to the start of the single buffer, and uses a pixel stride of 4.
The Magenta buffer info points to the second byte in the single buffer, and also uses a pixel stride of 4.
The Yellow buffer info points to the third byte in the single buffer, and also uses a pixel stride of 4.
The Black buffer info points to the fourth byte in the single buffer, and also uses a pixel stride of 4.
It’s also possible to use a different order for the components, insert a pad (say for RGBX results) or whatever else you need.
The actual rendering is the same as renderSeparations(), it's just a different output format. This also means that options like anti-aliasing will work without issue.
The other major change is that it supports an arbitrary number of separations. This allows us to support 4096 separations as per renderSeparations()even while rendering to frame buffers.