RFR: 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride [v2]

[Sergey Bylokhov]

On Fri, 25 Apr 2025 18:18:00 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> There is no reason to change our current implementation of ComponentSampleModel, since a similar raster can be created manually and should be properly handled by accelerated pipelines.
>> 
>>     DataBuffer manualBuffer = new DataBufferByte(
>>         scanlineStride * (SIZE - 1) + pixelStride * SIZE
>>     );
>>     WritableRaster manualRaster = Raster.createWritableRaster(sampleModel, manualBuffer, null);
>>     BufferedImage manualImage = new BufferedImage(colorModel, manualRaster, isAlphaPremultiplied, null);
>
> In your sample you provided an example, when raster fits whole pixels (`scanline * (height - 1) + pixelStride * width`), which, I agree, is a perfectly fine case and must be supported by accelerated pipelines. But the question is: should partial pixels be handled by our pipelines too (`scanline * (height - 1) + pixelStride * (width - 1) + maxBandOffset + 1` where `maxBandOffset + 1 < pixelStride`), or should whole pixels be enforced? I am for the latter.

However, this is not a case of a "partial pixel"- the data for the pixel itself is present. Therefore, the user can still manually create a buffer that discards the tail of the image and it will be accepted:

DataBuffer manualBuffer = new DataBufferByte(
    scanlineStride * (SIZE - 1) + pixelStride * (SIZE - 1) + 2/*maxBandOffset*/ + 1 /*size of last component*/
);

The current logic seems to imply that:

* The scanline stride doesn't matter for a single-line image, or for the last line in the image.
* The pixel stride is irrelevant if there's only one pixel in the image, or for the last pixel in a row.

This behavior is validated in src/java.desktop/share/classes/sun/awt/image/ByteComponentRaster.java#verify, with the exception of the single-pixel image we mentioned earlier.

I believe that exception for the 1-pixel image is a bug (pixelStride > data.length) that was overlooked during the work on commit [86104df](https://github.com/openjdk/jdk/commit/86104df#diff-f5003f18f0f4594a4859901ea950652467137fb1d07900208a84617036142746R891-L891), where a similar check for scanlineStride > data.length was fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2060763816