On Fri, 25 Apr 2025 18:18:00 GMT, Nikita Gubarkov <ngubar...@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
