> This resolves a gif parsing bug where an unwanted opaque rectangle could > appear under these conditions: > > 1. The disposal method for frames is 1 (meaning "do not dispose", aka > "DISPOSAL_SAVE") > 2. The transparent pixel is non-zero > 3. There's more than one such consecutive frame > > Previously: the GifImageDecoder would leave the saved_image pixels as zero > when they were supposed to be transparent. This works great if the > transparent pixel index is zero, but it flood fills the background of your > frame with the zeroeth color otherwise. > > I wrote four PRs that share the GifComparison class in this PR. Once any of > them clear code review the other PRs will be much simpler: > > 1. [8357034](https://github.com/openjdk/jdk/pull/25264) > 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one) > 3. [8356320](https://github.com/openjdk/jdk/pull/25076) > 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: - 8356137: trivial javadoc update - 8356137: only inspect last frame of gif This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.) This is in response to: https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25044/files - new: https://git.openjdk.org/jdk/pull/25044/files/62c2bf0d..e0546b1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=06-07 Stats: 92 lines in 1 file changed: 0 ins; 53 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/25044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044 PR: https://git.openjdk.org/jdk/pull/25044
