RFR: 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop

[Phil Race]

On Wed, 19 Oct 2022 02:59:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to improve the change made by the
> [8005530: [lcms] Improve performance of ColorConverOp for default destinations](http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/fd8810d50c99)
> 
> Right now the LCMSTransform mantain the special "imageAtOnce" flags and call cmsDoTransform function in the loop per line to support the gaps betwen the lines in the images . This code can be improved by using one call to cmsDoTransformLineStride. Some discussion about this method can be found [here](https://github.com/mm2/Little-CMS/issues/314), the full [specification](https://github.com/mm2/Little-CMS/blob/master/doc/LittleCMS2.14%20API.pdf):
> 
> 
> void cmsDoTransformLineStride(cmsHTRANSFORM Transform,
>                               const void* InputBuffer,
>                               void* OutputBuffer,
>                               cmsUInt32Number PixelsPerLine,
>                               cmsUInt32Number LineCount,
>                               cmsUInt32Number BytesPerLineIn,
>                               cmsUInt32Number BytesPerLineOut,
>                               cmsUInt32Number BytesPerPlaneIn,
>                               cmsUInt32Number BytesPerPlaneOut);
> 
> This function translates bitmaps with complex organization. Each bitmap may contain
> several lines, and every may have padding. The distance from one line to the next one is
> BytesPerLine{In/Out}. In planar formats, each line may hold several planes, each plane may
> have padding. Padding of lines and planes should be same across all bitmap. I.e. all lines
> in same bitmap have to be padded in same way. This function may be more efficient that
> repeated calls to cmsDoTransform(), especially when customized plug-ins are being used.
> 
> Parameters:
> 
> -  hTransform: Handle to a color transform object.
> -  InputBuffer: A pointer to the input bitmap
> -  OutputBuffer: A pointer to the output bitmap.
> -  PixelsPerLine: The number of pixels for line, which is same on input and in output.
> -  LineCount: The number of lines, which is same on input and output
> -  BytesPerLine{In,Out}: The distance in bytes from one line to the next one.
> -  BytesPerPlaneIn{In,Out}: The distance in bytes from one plane to the next one inside a line. Only applies
>                             in planar formats. 
> 
> 
> Notes:
> - This function is quite efficient, and is used by some plug-ins to give a big
>   speedup. If you can load whole image to memory and then call this function
>   over it, it will be much faster than any other approach.
> - BytesPerPlaneIn{In,Out} is ignored if the formats used are not planar. Please note
>   1-plane planar is indistinguishable from 1-component chunky, so BytesPerPlane is
>   ignored as well in this case.
> - If the image does not have any gaps between the pixels and lines BytesPerLine{}
>   are equal to the pixel's size * PixelsPerLine.
> - To specify padding between pixels, use T_EXTRA() and EXTRA_SH() to specify
>   extra channels.

This all looks good and I see that cmsDoTransform ends up in the same place as cmsDoTransformLineStride
so the performance of the "simple" case should be no worse.

I am just waiting for my test run to complete before approving.

Hmm I wonder if this will have a merge conflict with https://github.com/openjdk/jdk/pull/10459
Probably best to integrate that one FIRST because I need to co-ordinate closed changes there.
Then if this one needs a merge you can do it .. which would be tricky for me to deal with for the other one.

-------------

PR: https://git.openjdk.org/jdk/pull/10754