On Mon, 24 Nov 2025 22:50:56 GMT, Sergey Bylokhov <[email protected]> wrote:
>> The spec update in question only applies to the pre-defined types. >> I see no circumstance in which we'd ever modify the implementation of these. >> >> I actually tried this (meaning BandedSampleModel) months ago now, for the >> 3BYTE_BGR case which is the one of those with the biggest current >> constraint. ie. I changed the implementation of that case and found that >> printing, Image I/O and IIRC at least one >> other thing I can't remember now assumed the current implementation. >> They'd need to be re-worked first. I don't see this ever happening. >> If internal code makes assumption, external code likely does too. >> >> If we did add a new pre-defined type that can exceed these limits because it >> used a banded raster, then as part >> of adding that, updating the spec for this case would be part of that. And >> that could never be backported anyway. > >> If we did add a new pre-defined type that can exceed these limits because it >> used a banded r > > I agree with this. It will be hard to reimplement, but maybe we can still > hint that this behavior depends on the implementation rather than specifying > it strictly in the documentation? It does not say that something like TYPE_4_BYTE_ABGR absolutely cannot use bands. It just points out that if you use a smaller data buffer type you can store less data *in a DataBuffer* than with a larger one, with the end result being more of a limitation on the image size. This result just scales with the number of bands used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586909864
