On Fri, 24 Oct 2025 21:22:40 GMT, Sergey Bylokhov <[email protected]> wrote:
>> You mean keep the original returned float[] color separate from the one >> that's later over-written. >> I'd thought about that but I don't think it is worth it. >> It can also be over-written at line 835. There's just too much state >> tracking needed to save >> the GC a tiny bit of effort freeing small transient objects. >> Also it already is re-initialised for each scanline. See line 807, so it >> isn't (quite) the same array for the entire image anyway. > >> It can also be over-written at line 835. > > Interesting, is it possible that that line has the same bug? > `color = dstColorSpace.fromCIEXYZ(dstColor);` > Does dstColor always have the same number of components as CIEXYZ? > > Is the logic of using CIEXYZ for mix of non-/ICC source and non-/ICC > destination actually correct? fromCIEXYZ is defined on ColorSpace, not ICC_ColorSpace. It requires 3 (or more) components, and then dstColorSpace will return an array of colors in its own colorspace. The dstColor parameter is always created with at least 3 components based on the dstNumComp And if there's no bug in dstColorSpace it should return an array of the right length for itself. So if there's a bug it isn't obvious to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2462083087
