RFR: 8357034: GifImageDecoder can produce wrong transparent pixels [v7]

[Jeremy Wood]

On Fri, 22 Aug 2025 23:52:39 GMT, Phil Race <prr at openjdk.org> wrote:

> But what was wrong with frame-by-frame, that "all subsequent frames" fixes ?

I'm not sure I understand what you're asking; this bug demonstrates what was wrong with the frame-by-frame response.

Another way to phrase it might be:

A gif works with a fixed color palette of n-many colors. But if you want to be clever: you can switch which pixel is the transparent pixel index, and as you layer frames you can end up with an image that has (n+1)-many colors. The +1 is a transparent pixel.

This demo, for ex, features a 4-color palette: red, yellow, green, cyan. But using this palette we can create an image that is red, yellow, green, cyan AND transparent.

If you process the incoming data "the easy way": we just do a raw dump of the incoming pixels. This forces us back to the 4-color palette *of the current frame*. But if we do it "the hard way": we're processing only the opaque clusters of incoming pixels, which lets us end up with (n+1)-many colors.

If that description helped: great. If not: please disregard. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2295067500