On Wed Jun 17 00:58:57 2026 +0000, zhengyong chen wrote:
You are right。But it does not load all pixel data into persistent memory. It reads compressed sub-blocks through a small fixed buffer（256 bytes） to advance the stream, but discards the data immediately after each sub-block. The READ call advances the stream position (which is necessary to reach subsequent frames), but the actual memory footprint stays constant at 256 bytes — compared to the old approach which would allocate width × height bytes per frame and keep them all. You might wonder why we don't simply use seekFunc to skip over the LZW image sub-blocks. The reason is that GIF is a purely sequential format with no index table. Each frame's LZW compressed data consists of a chain of sub-blocks (length prefix + data), terminated by a single 0x00 byte. Without reading through the sub-block chain, there is no way to know where the current frame's pixel data ends. The only way to determine frame boundaries is to read sequentially through the sub-blocks until the terminator is reached.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11149#note_143310