> 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.
Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - Merge remote-tracking branch 'upstream/master' into JDK-8295430 - 8295430: Use cmsDoTransformLineStride instead of cmsDoTransform in the loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10754/files - new: https://git.openjdk.org/jdk/pull/10754/files/1c017aac..03c3c849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10754&range=00-01 Stats: 196675 lines in 1649 files changed: 100914 ins; 62184 del; 33577 mod Patch: https://git.openjdk.org/jdk/pull/10754.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10754/head:pull/10754 PR: https://git.openjdk.org/jdk/pull/10754
