On Mon, 26 May 2025 05:30:55 GMT, Jeremy Wood <d...@openjdk.org> wrote:
>> I do not have much background in LZW compression or in C, but I'm reasonably >> confident this resolves the problem I'm observing. It looks like the >> GifImageDecoder was not always correctly handling compression codes after >> the table reached its limit of ~4096. If anyone has suggestions for >> improvements I'm happy to make adjustments. >> >> Luckily while debugging this: I was able to compare the flawed >> implementation (GifImageDecoder) with ImageIO's implementation >> (GIFImageReader) to help identify how the suffix/prefix tables are supposed >> to work. >> >> ImageIO's implementation may have suffered a similar bug (maybe >> https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have >> been backported. >> >> I have dozens of additional test cases for this problem, but unfortunately I >> don't have the rights to commit them to the OpenJDK repo. Feel free to email >> me for additional context/test cases. >> >> 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) >> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) >> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one) > > Jeremy Wood has updated the pull request incrementally with one additional > commit since the last revision: > > 8356137: Adding copyright to GifComparison I'm assuming (?) there's a compelling reason to preserve the GifImageDecoder. ImageIO's decoder appears to avoid all the bugs I've observed in the ToolkitImage's implementation. If they are redundant: we could just rewrite the GifImageDecoder to rely on ImageIO . ------------- PR Comment: https://git.openjdk.org/jdk/pull/24271#issuecomment-2997036336
