[Webkit-unassigned] [Bug 15141] New: GIFImageReader can decode incorrectly at different packet boundaries

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15141

           Summary: GIFImageReader can decode incorrectly at different
                    packet boundaries
           Product: WebKit
           Version: 522+ (nightly)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Images
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zerodpx at gmail.com


WebCore/platform/image-decoders/gif/GIFImageReader.cpp (not used by Safari, but
used by Cairo/QT) has bugs relating to how it was borrowed from the Mozilla
codebase, which provides data to the decoder differently.

In the Mozilla world, the decoder is called with only the new data seen since
the last call, so a hold buffer is used to store not-yet-decoded data that
should be prepended to the next incoming chunk.  In the WebKit world, the
decoder is provided the entire data stream up to the current point every time. 
To fit these two together, GIFImageDecoder.cpp contains some wrapper code that
lets the reader call back to say "I've decoded up to this point", and then the
wrapper will call the reader with only the data from there the next time.

The problem is that this callback isn't actually used in a couple places where
it should be, meaning that depending on where your packet boundaries are, GIFs
fail to decode or decode incorrectly.

The true fix to this would be to rewrite the reader and its wrapper to
eliminate the hold buffer entirely and be fully aware of the way data is going
to be provided.  However, that's a slightly trickier task than what I propose
to do in this bug, which is to at least insert the necessary callback calls so
that the decoder always gets data from the right point.  Patch coming shortly.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.