[Webkit-unassigned] [Bug 146205] New: Decoding of animated PNG (APNG) is not optimized for memory usage.

[bugzilla-daemon at webkit.org]

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

            Bug ID: 146205
           Summary: Decoding of animated PNG (APNG) is not optimized for
                    memory usage.
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: cgarcia at igalia.com, maxstepin at yahoo.com

The current code for decoding animated PNGs (see bug 17022.) decodes all frames at once
and loads the raw pixels on memory for each frame.

This is a problem when we have an animated PNG with many frames.

Take the following example:

http://people.igalia.com/clopez/apngmem

The image loaded (clouds.png) has 375 frames at 700 x 394 (8-bit/color RGBA),
so when each frame of this image is loaded into memory it uses:

700*394*4 ~ 1.05 MB

That should be ok if the image had only a few frames, however it has 375 frames,
so when we load all the 375 frames into memory we end using around ~400MB,
which is too much.


The current PNGImageDecoder decoder implements PNGImageDecoder::clearFrameBufferCache(),
which helps to clear the already displayed frames. So if you check the memory
usage of WebKitWebProcess when the example test page is playing the animation,
you will see that the memory used by WebKitWebProcess lowers as it displays
the animation, however when the animation ends and starts again, the memory usage
peaks again because it decodes all the frames into memory again.


So, instead of loading all the frames on memory at once, I think it should be better
if it loads the frames on demand as the animation shows on the screen.


The GIF decoder has a parameter named haltAtFrame that seems designed to 
avoid this very same isue. See:
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp?rev=185822#L299
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp?rev=185822#L354

For example, check loading this gif (1116 frames at 800 x 800) <http://people.igalia.com/clopez/apngmem/giant-redacted.gif>
on the WebKitGTK+ MiniBrowser and on some image viewer (eog, ristretto, ...).

You will see that on the WebKitGTK+ MiniBrowser it only uses a few megabytes
while on the image viewer it would use so much ram that it will end being killed by the OOM.

I have converted this gif to png with gif2apng. The result is here <http://people.igalia.com/clopez/apngmem/giant-redacted.png>
If you download it and open with WebKitGTK+ you will see that it uses a lot of ram. While with the gif version that don't happens.

So, I think that the png decoder should gain support to only decode the frames
up to a haltAtFrame parameter like the GIFImageDecoder does.

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