|
Harlequin RIP SDK
|
|
|
|
Harlequin RIP SDK
|
|
Read/write structure used during the DeviceIOCtl_RasterBandSize IOCTL calls. More...
#include "swraster.h"
Data Fields | |
| size_t | size |
| HqBool | handled |
| size_t | max_one_band_size |
| HqBool | use_dynamic_bands |
| struct sw_datum * | raster_params |
| RASTER_LAYOUT * | raster_layout |
Read/write structure used during the DeviceIOCtl_RasterBandSize IOCTL calls.
| HqBool RASTER_BANDSIZE::handled |
Flag which is set to FALSE by the caller, and set to TRUE by the callee if it has done everything it needs to do. If not, the caller will keep calling with the same data until either this flag is set to TRUE or the callee returns an error.
| size_t RASTER_BANDSIZE::max_one_band_size |
Maximum size of one band, in bytes. The callee can set this to limit the size of a single band allocated by the RIP, or zero to allow the largest band sizes the RIP can manage.
| RASTER_LAYOUT* RASTER_BANDSIZE::raster_layout |
The raster layout for the pagedevice. If the raster backend wishes to access this structure after the call is finished, it should call raster_layout_acquire() to get a pointer that will remain valid, or copy the layout into its own memory using raster_layout_copy(). Pointers acquired using raster_layout_acquire() must be released using raster_layout_release() before the RIP shuts down.
The raster bandsize call may be used to modify the linesize and alignment fields in each of the planes in this layout.
| struct sw_datum* RASTER_BANDSIZE::raster_params |
Optional structured data for raster parameters. If the raster backend wishes to access these parameters after the call is finished, it should either unpack them into its own variables, or use the sw_data_api::retain() and sw_data_api::release() functions to preserve the data tree.
| size_t RASTER_BANDSIZE::size |
Size of this structure.
| HqBool RASTER_BANDSIZE::use_dynamic_bands |
Should the RIP try to allocate extra dynamic bands, above the number of rendering threads in use? Dynamic bands are only useful if the output is being handled asynchronously (RASTER_REQUIREMENTS::rip_handles_bands is FALSE), the extra band(s) may allow the RIP to render ahead of the output. There is no guarantee that dynamic bands will be used, even if requested. The RIP initializes this depending on the value of the DynamicBands system param. The callee should set this to FALSE if dynamic bands are not desired: changing this value will have no effect if it is not TRUE on entry.