On Tue, 4 Mar 2025 23:13:02 GMT, Jeremy <d...@openjdk.org> wrote:
>> src/java.desktop/share/classes/javax/imageio/ImageTypeSpecifier.java line
>> 923:
>>
>>> 921: int bufferedImageType = ((BufferedImage)image).getType();
>>> 922: if (bufferedImageType != BufferedImage.TYPE_CUSTOM &&
>>> 923: bufferedImageType !=
>>> BufferedImage.TYPE_BYTE_INDEXED) {
>>
>> So we'll no longer use a singleton IST for images with an ICM.
>> I don't know how much that matters though. They probably aren't heavyweight
>> compared to the image writing.
>> The alternative - which I'll mention, which isn't the same as recommend - is
>> to check if ColorModel.getTransparency() == OPAQUE before using the
>> singleton, since we know that's the case it maps to.
>>
>> The BYTE_INDEXED case code in getSpecifier(..) isn't dead code, because it
>> is still used in
>> public static ImageTypeSpecifier createFromBufferedImageType(int
>> bufferedImageType)
>> In that case, there's not enough information to do anything except "pick
>> one", so it is caveat emptor for callers of that API in such a case, and no
>> need to do anything there.
>>
>> I'll have to run this through our testing.
>
> Right.
>
> If we value cached singletons: it'd be easy to break this up into 3 basic
> cached ImageTypeSpecifiers (one for each Transparency constant: OPAQUE,
> BITMASK, TRANSLUCENT). That would also satisfy the attached unit test and the
> original TwelveMonkeys complaint. I started with what I thought was the
> simplest proposal (in this PR), but I'm happy to explore other options if we
> want.
Unless someone has a performance-sensitive batch job encoding thousands of
transparent GIFs, I don't see a problem.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23884#discussion_r1980415741
