<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.

Pixel Patch Device Method Proposal

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.

First attempt

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: