<aside> š https://ghostscript.com/r/Pixel-Patch-Device-Method
</aside>
More than a proposal, this has now been implemented. The document is left here for reference.
At various points in Ghostscript, we are forced to convert from an array of pixel values to a series of fill_rectangle calls. While this is, surprisingly, not the massive bottleneck we might expect, avoiding this would save us time, and admit of some other optimisations.
Iām pondering some new device methods that should help this. This page is to record my train of thought, and to provide a place for comments from other interested parties.
We could add:
int begin_pixel_patch(gx_device *dev, fixed x, fixed y, fixed w, fixed h,
int src_x, int src_y, int landscape,
gx_pixel_patch_enum_t **ppenum);
together with:
int pixel_patch_data(gx_pixel_patch_enum_t *penum, const byte **data, int data_x);
int pixel_patch_end(gx_pixel_patch_enum_t *penum);
The idea would be that when something has a block of pixel data to pass across to a device, it can call this function rather than break it down into rectangles.
The classic example of where we need this is inside functions like image_render_mono
or image_render_color_icc_portrait
which convert scanlines worth of data into the target colorspace, and then end up having to convert it down to individual fill_rectangle
calls.
The default implementation of this routine can thus be lifted from image_render_mono
and friends, and we can call it with no significant decrease in speed in the worst case.
Some salient points:
Problems with this: