[Webkit-unassigned] [Bug 177864] New: [GTK][WPE] GIFImageDecoder never clears decoded frames even when told to do so

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=177864

            Bug ID: 177864
           Summary: [GTK][WPE] GIFImageDecoder never clears decoded frames
                    even when told to do so
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: magomez at igalia.com
                CC: bugs-noreply at webkitgtk.org

While testing the fix for https://bugs.webkit.org/show_bug.cgi?id=176089, I realized that there was something weird going on with GIFImageDecoder::clearFrameBufferCache(). Despite I was being called, it wasn't really freeing any buffer. Due to this, all the decoded frames will stay in the cache and consume tons of memory instead of respecting the limit of 30MB.

The fix to properly delete frames from the cache is trivial, but doing so triggers an unexpected issue:
clearFrameBufferCache() receives a clearBeforeFrame parameter, searches backwards for the frame required to render clearBeforeFrame (clearing unneeded frames in between), and then clears all the buffers before the required one. This is because it expects that the next frame rendered will be clearBeforeFrame, and in order to accelerate that we keep the required frame decoded.
The problem comes when, after that, we request to decode a former frame that was cleared from the cache. We can't start decoding that frame directly because it may depend on a former frame. So we would need to find that former frame and decode it first. This causes that the fix for https://bugs.webkit.org/show_bug.cgi?id=176089 doesn't work once clearFrameBufferCache is working properly, because it would start decoding the required frame.

The proper fix for this would be, besides fixing cleatFrameBufferCache(), implementing a function to find the frame that is required to render the requested frame, and start decoding from there. We could just decode always from frame 0, and it would work, but it would be very inefficient.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171004/be991260/attachment.html>