New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 884 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Duplicate
Merged: issue 437662
Closed: Oct 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 1171: Request for enhancement: APNG (animated PNG)

Reported by, Sep 4 2008

Issue description

Product Version      : 
URLs (if applicable) : <see below>
Other browsers tested: Opera 9.52 OK
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: FAIL
    Firefox 3: OK
         IE 7: FAIL

What steps will reproduce the problem?
1. View an APNG file

What is the expected result?
All frames of animation are shown.

What happens instead?
Only the first frame is shown.

Please provide any additional information below. Attach a screenshot if

I am just creating this as a request to add this feature to WebKit and Chrome.
Showing comments 7 - 106 of 106 Older

Comment 7 Deleted

Comment 8 Deleted

Comment 9 Deleted

Comment 10 Deleted

Comment 11 by, Mar 2 2010

 Issue 34004  has been merged into this issue.

Comment 12 Deleted

Comment 13 Deleted

Comment 14 Deleted

Comment 15 by, Mar 15 2010

Talk to the libpng guys and get them to accept the patch from here: ... otherwise, its not gonna happen as Webkit/Chrome both 
use the vanilla libpng library!

Comment 16 by, Mar 15 2010

If APNG support landing in libpng is a prerequisite, then this functionally becomes a wont_fix. To quote the 
APNG proposal vote:
>> Voting has closed on the APNG proposal.  There were 8 YES
>> votes, 10 NO votes, no abstentions, and no ineligble votes
>> cast.  The proposal has failed and the APNG chunks are not
>> registered.
>It's unfortunate that full acceptance of the proposed usage of the 
>chunks is required to register public chunks that may/will be used by 
>multiple vendors.  I haven't looked at many other similar standards, but 
>I believe that for TIFF, all that's needed is a form submitted to Adobe. 
>  Combined with the requirement that there basically be twice as many 
>YES votes as NO votes, this makes it unlikely that APNG will ever be 
>accepted in any form by this group as long as some of APNG's original 
>core goals are not violated -- or, worse yet, the APNG chunk names will 
>not be able to be reserved for usage by multiple vendors, regardless of 
>their purpose...
>There are pretty serious disagreements regarding: a) the use of the PNG 
>signature; b) the fallback image type (single-image vs. montage); c) the 
>definition of a "good" fallback image (the data loss issue); d) various 
>feature additions/omissions (JNG/JPEG support, sprites, etc.).  The 
>first of these, the PNG signature issue, seems to be the most 
>intractable issue.

Comment 17 by, Mar 16 2010

> Webkit/Chrome both use the vanilla libpng library!

But that's exactly the point of this request: to switch Webkit/Chrome from vanilla
libpng to apng-patched libpng.

Comment 18 by, Mar 16 2010

> But that's exactly the point of this request: to switch Webkit/Chrome from vanilla
libpng to apng-patched libpng.

Originally, I thought that doing this would require a lot of work/maintenance for the 
Webkit team as they would have to fork and maintain a new library. However, after 
some inspection, it seems the libpng library itself has reached a level of maturity 
such that it it not changing much at all anymore. In theory, this should make 
maintaining a fork of this particular library very easy.

Additionally, it seems as though the reason the libpng team decided against adopting 
the patch into their mainline by a vote of 8 to 10, was a matter of maintaining a 
"purity" of the standard for the image file format. So, I guess the real question for 
the webkit guys here, is whether or not apng support would dillute the image format 
or not. We already know the Mozilla guys don't think so :)

Comment 19 by, Mar 16 2010

> So, I guess the real question for 
the webkit guys here, is whether or not apng support would dillute the image format 
or not. We already know the Mozilla guys don't think so :)

I agree with them. It wouldn't affect any existing PNG files. It would just make the ones that are APNG work.

My biggest reason for wanting APNG is the 8-bit alpha. You can produce some pretty neat throbbers with that. 
With GIF, to make a really cool-looking throbber, you need to have a consistent background color for your 
page. I've even seen a few pages that have a background image, a nice glossy transparent design (using PNGs, 
CSS, and whatnot), and then have a big white slab just to put the GIF throbber on :D

Comment 20 Deleted

Comment 21 Deleted

Comment 22 Deleted

Comment 23 Deleted

Comment 24 by, Apr 18 2010

Funny how some of these bug reports turn into petitions....

Any chromium developers able to ring in on this, so we can get a definitive answer for whether to continue 
hoping for this or give up hope completely?

Comment 25 by, Apr 20 2010

Choice is good- an alternative to animated GIF could open up new routes for content creation.  I would like to 
see this added.

Comment 26 by, May 10 2010

I'm using APNGs in my web-apps. They work fine with Firefox, it was very 
disappointing to note that my web-apps stopped working properly in Chrome for this 
missing feature.

I cannot use GIFs since they do not work correctly with transparencies and i 
certainly won't use that crap of Flash.
This means that i have to push my users the use Firefox instead of Chrome and it is 
not something i like to do since i do believe that Chrome would make my web-apps 
faster and more responsive.

I hope the Chrome team will reconsider their position on APNGs and, in this way, let 
us developers get rid of those old, ugly GIFs that have haunted the WEB with their 
dumb limits from its beginning.

Comment 27 by, Jun 7 2010

APNG is the only other widely used animation image format used besides GIF, which is heavily dated.

Comment 28 by, Jun 10 2010

I wouldn't call APNG widely used.  Only places I've seen it used are in examples of APNG usage.  There is a need for post-GIF animating image support, and APNG may probably a good choice since Firefox already implements it.

On the other hand, there are no tools that I'm aware of that can produce APNG files, other than a Firefox-based editor which is hard to use.  That's probably the bigger barrier here, actually.

Comment 29 by, Jun 10 2010

Correction: The last time I checked, which granted was a while ago, I could not find any good APNG generating tools that I liked.  My favorite image editing tools (GIMP mainly, Irfanview too but it really needs proper alpha channel support first) have no support for APNG (again, last I checked, I should check again I suppose).

Comment 30 by, Jun 10 2010


There's the APNG assembler. It works really well, and it's not too much of a pain.

Plus, if more browsers support it, it will surely get into image editors quite quickly.

Comment 31 by, Jun 16 2010

Yes, megazzt, you should check again. May I suggest this list:

Comment 32 by, Jun 30 2010

Just found out that apng is not supported in chrome. I'm developing for both firefox and chrome compatibility. Add it pretty please with lots of sugar on top of it :-)

Comment 33 by Deleted ...@, Jun 30 2010

APNG isn't a good format as it's impossible to differentiate between normal png and animated png without opening it and probing its headers. This causes unnecessary headache for web developers and is one of the reasons why the PNG group officially rejected this format. Which is why APNG is widely consideren non-standard as only Firefox supports it.

Comment 34 by, Jun 30 2010

Opera supports it too.

Comment 35 by, Jun 30 2010

So since APNG is rejected by libpng and therefore (unofficially) by
Chrome/Safari, I'm interested in knowing if there is an alternative file
format to the APNG that has more chance of getting support across all

Comment 36 by, Jun 30 2010

SVG with SMIL seems more appropriate for small animated icons and when gzipped, should usually be smaller in file size.

Comment 37 by, Jun 30 2010

SVG+SMIL is significantly more complex, both in terms of constructing images of that type and the implementation to render them. All that is really required here is a simple file format for animated alpha transparent bitmaps. APNG fits that requirement very nicely with a minimal amount of fuss. From what I could tell, APNG was rejected by the libpng guys mostly for political reasons, they are still pushing their MNG format(s) despite complete lack of interest from the wider community for over a decade.

Either someone needs to put their weight behind MNG Very Low Complexity, or APNG. As APNG already seems to have some momentum behind it, I say go with that. This does not preclude MNG later taking over, if they get their act together and show why it is superior.

Comment 38 by, Jun 30 2010

If you need an animated bitmap format, there are tons of video formats to choose from. If you need an animation format that supports transparency, it is almost always for UI elements, and SVG+SMIL is the way to go. Unlike APNG, SVG+SMIL's clickable area for said UI element can be any shape (eg. to not count clicks on the transparent area) and APNG only support a rectangle (without the use of area tags).

Comment 39 by, Jun 30 2010

Thanks for the information about SVG+SMIL, I didn't yet know that. It seems
like a nice alternative of doing animations, it isn't an alternative for
bitmap-animations. I would guess that doing stuff like animating fire is
very hard to do that way.

I've also been thinking of the 'alternative' by using the video-element. I
don't know how well supported that will be for mini-video's. At the moment
it is way too bloated as an alternative to apng, but it's something to keep
in mind, maybe that'll change in the future.

The 'MNG: Very Low Complexity' looks ok. It isn't as bloated as the full MNG
specification, but therefore it seems to have almost the same features as
APNG. One big difference I think is that APNG can be loaded as a still image
as if it was a PNG image. I don't know if that is an advantage or
disadvantage. There was also a discussion on this on mozilla's bugtracker:

Comment 40 by, Jun 30 2010

SVG can store bitmap data, can it not? So just change the data being viewed and you've got yourself APNG in SVG.

Comment 41 by, Jun 30 2010

If you're okay with storing a complete image for every frame, then yes, technically SVG+SMIL can make bloated animated PNG.

frozencow: Video formats are *less* bloated (in terms of file size) than APNG, even for, say, a small 60-frame animation.

Comment 42 by, Jun 30 2010

You have to understand that libpng was never intended to be one and only implementation of PNG format. It's only a *reference* implementation.

PNG is quite simple, it's very easy to write your own implementation
(on top of zlib library). You would only need to read/handle those PNG chunks 
you care about, and ignore all others. And if you need to read/handle 
three APNG chunks, no problem, do it the same way.

Just because libpng won't support every chunk invented by a third-party, doesn't mean all third-party PNG extensions are doomed. 

Remember, PNG was designed to be extendable by others. It's in the specs.

Comment 43 by, Jun 30 2010

Now, about MNG.

> The 'MNG: Very Low Complexity' looks ok.

No it's not. 

First, MNG-VLC still has that awful MAGN chunk. It's a useless too complex bug magnet.

Second, MNG-VLC is missing Delta-PNG, so you cannot save only the pixels that changed from the last frame. This issue is hugely important for compression. 
APNG wins here.

PNG/MNG people attempted to introduce MNG 2.0 to address those problems, but they lost interest for some reason. Too bad. Now APNG has no alternatives.

You can read about their "MNG-2.0 proposal" here:

Comment 44 by, Jun 30 2010

CSS animation or transformation would be a much much better alternative to all this. The saddest thing is that the most well rounded solution at the moment between all browsers is a simple frame-by-frame animator using Javascript with gif fallback... the APNG file being a stupid 50kb while a frame-by-frame PNG equivalent only being 6kb!

Out of all potential options (APNG, MNG, SVG, JS frame-by-framing, CSS animation, etc..) a proper implementation of CSS animation would be the BEST option as it would allow so many other things other than "spinners".

Comment 45 by, Jul 1 2010

Chromium developers, are you thinking that?
You are developers, Google is sponsor... We are users and web*(master|designer|architect...) and we have the control of choice.
Simply we can write website for any others rendering engine and boycott webkit.
Sounds like to you (developer, Google and Apple)? ;)

Remember Microsoft Internet Explorer war...

Comment 46 by, Jul 1 2010

Are those better options? Well, maybe to a certain extent. There is a certain ease of use, and simplicity in being able to use an animation. That's why GIF images have remained in use for so long. I would love to be able to add some subtle effects to my web pages with what APNG can provide. Years ago, I would have pushed for MNG support, and if Chrome chose that path, I would still approve. MNG is a well document, powerful, and open format; but the complexity comes at a cost of ease in implementation. Hence, the development of APNG.

A better question than "are there better alternatives" is "why not?". APNG was specifically developed as a format for providing an animated "GIF-like" image without the limitations of binary transparency and 255 colors. Despite being an "unofficial" extension to PNG, the very simplicity and practicality of the format have given it a great deal of momentum.

What we, as technical netizens, are requesting, is that the Chrome developers simply utilize and incorporate the patches already available in the PNG library to give us the ability to use a format with great potential. The success or failure of a format is far more reliant upon the embrace of a community, than that of a board of directors. If you don't want to tout the support of APNG is a feature of Chrome, then don't, but having it available certainly can't hurt!

Comment 47 by, Jul 1 2010

> CSS animation or transformation would be a much much better alternative to all this.

In what application would you make them?

> the APNG file being a stupid 50kb while a frame-by-frame PNG equivalent only being 6kb!

This can't be. You obviously doing it wrong.

Comment 48 by, Jul 14 2010

SVG files are a horrible alternative because of the complete lack of compatibility with IE6,7 & 8. CSS Transformations are slightly better in that aspect because(unlike SVG) it'll at least show the first frame. But you can't just upload an image with automatically has CSS transitions, its far easier to have a simple animated image format.

Opera and Firefox did it, I don't see why Chrome wouldn't

Comment 49 by, Jul 20 2010

APNG has been rejected by the PNG-Developers, as APNG is a mix of animation an stand alone image. Therefore, MNG is the only offical animated PNG format anyone should use (as Gimp does, for example).


Comment 50 by, Jul 20 2010

The problem, bmarwell, is that MNG is a complex format with almost no support. The one decent web browser that did support it for a while was Konqueror 3.5. Even the KDE developers, though, have removed MNG support due to complexity and lack of use. As long as MNG does not show up AT ALL in ANY MAJOR BROWSER it is for all intents and purposes, useless.

APNG was designed specifically so that in browsers that to not understand it, such as Internet Explorer, it will simply present the first frame as a valid PNG image. It is not an official solution, but it is a practical one. Similarly, the format is simple enough to be supported easily. Firefox and Opera, two of the major browsers DO support APNG, and the other browsers show (correctly) the first frame. This is something that web developers can work with today.

I'm all for pushing MNG support in Gecko, Webkit, Presto, and Trident (Good luck on MNG support in Trident!), but for now, APNG is simply a good clean transition, and I hope for Google to take the lead in their fork of Webkit and support it.

Comment 51 by, Jul 20 2010

At the moment, I am doing JavaScript sprite based frame-by-framing that seems to work pretty well in most browsers (and offers much more flexibility). Not very practical for mobile use, but the file size difference alone is staggering (8kb instead of 50kb+ for an APNG).

Comment 52 by, Jul 20 2010

But that doesn't work at all on websites where users post images, such as forums etc. The only way to do it then is to have an animated image format.

Comment 53 by, Jul 22 2010

Personally, while I'd like to see APNG included, I'd be happy with MNG too.  APNG support is one of the reasons I haven't switched over from Firefox yet.

Comment 54 by, Aug 4 2010

Anyone tried to compare the converters?

Comment 55 by Deleted ...@, Aug 4 2010

mng ...
What a bad idea.
Why would any webdeveloper want to use something supported by no one end not even backward compatible ?

Apng in the other hand is a good idea, even if majors browsers doesn't support it, webdeveloper can use it because of it backward compatibility with png.
Apng is an example of why free software are great.
If the official version doesn't feet your needs you can use or develop an other one.
But some seem to forget it and stay captive of one lib because it's the "official one"

It's free software !
If chromium team want apng and libpng team don't, so be it, and go for an other lib.

"We want apng but we can't have it because we HAVE to use vanilla libpng"
... Pathetic.

Comment 56 by, Aug 5 2010

@gnarkol: Very good point. I totally agree with you. 

Let's hope for apng-support in gimp, then ;-)

Comment 57 by, Aug 12 2010

Another vote for apng support.  The SVG options are processing intensive.  Check your CPU utilization if you don't believe me.  They have their place, but I'd rather have apng.  Please ...

Comment 58 by, Aug 13 2010

Another vote for APNG support.

Comment 59 Deleted

Comment 60 by Deleted ...@, Aug 13 2010

What some developers don't seem to understand is that what web designers and users want is not PNG (as in PNG + MNG), but a better GIF. APNG has become somewhat a better GIF. And that's all that we need. One single format to do everything. (.mng? C'mon!)
A compact, portable, modern bitmap format with added animation, in one easy, simple container.

Has some of those developers stopped to think why GIFs are still being used?
I haven't used a GIF for static bitmaps for quite some time. Regular PNG has superseded that. GIFs are still used for animations all over the web. (Man! there's even places dedicated solely to animated GIFs!)
Small effects, little animations, emoticons, etc.

What are the alternatives?

Which format? what codec? We know what's happening with video...
Besides, not all sites accept video if you want to upload an animation.

Ugh! Won't even mention THAT.

CSS Transforms?
Maybe in 10 years for IE...

Can you render that inline as any bitmap? (I really don't know)
Also, you know what the "V" stands for, right?
Maybe good to replace the Flash monstruosity, but not for a simple animated bitmap.

Don't even mention anything related to Javascript/ECMAscript. There's no way to use that outside of things you own. Not to mention script blocking utilities...

So, +1 for APNG for me. It's what a better GIF should be. MNG is DEAD. If it was CompuServe instead of the PNG folks with their "we know better than you what you need" attitude, APNG would be part of the spec (and libpng) for some time now.

GIMP developers used to be like that... and finally had to surrender to users complaints with the interface.

If Webkit browsers implement APNG, then the users will benefit greatly, and PNG will finally displace GIF as the lossless bitmap format for the web.

(Sorry for previous comment, forgot to vote, duh!)

Comment 61 by, Aug 13 2010

There seems to be quite a bit of FUD about SVG+SMIL here. First off, no, a simple transparent animated loading throbber does not use that much of your CPU at 18x18px (which seems like a reasonable size for a loading throbber).

> Can you render that inline as any bitmap?

It's not a bitmap, so I'll be ignoring that part of the question. Yes, with an inline <svg>, <object data="foobar.svg">/<iframe src="foobar.svg">, and <img> in the most WebKit browsers, Opera, and Firefox 4 beta 4.

> CSS Transforms?

IE invented CSS transforms, and supports quite a bit of them (albeit as proprietary Microsoft values for the filter property).

Real video formats are almost always more appropriate for captures of video. All you have to do is do H.264 + Flash for IE and WebM+<video> for everyone else.

> Besides, not all sites accept video if you want to upload an animation.

So you're saying APNG is a great way to skimp site rules? Sites like that would usually block multi-frame GIFs too. Even 4chan explicitly blocks APNG images.

Also, SVG+SMIL works in all browsers if you give IE the svgweb handicap.

> Also, you know what the "V" stands for, right?

You've got to be kidding me. Are you trying to imply that having a scalable interface is a bad thing? The amount of processing that goes into an 18x18px SVG loading throbber is negligible.

Comment 62 Deleted

Comment 63 by Deleted ...@, Aug 13 2010

@iSephir: :)
You are misunderstanding my message. Probably I've not made myself clear enough, sorry, as English is not my main language.
The bottom line could be something like this: use vector formats for vector images, use video formats for video sources, use bitmap formats for bitmaps images.
I love vector formats, but that's when I'm working with vectors.
I don't know why there's the impression that vectors can be used for everything. Well, no. If you're animating a vector illustration I understand the use of a vector format. But if you want to animate other things (bitmaps), maybe a raster format is best suited.

Someone needs to explain me the popularity of places like "Senor GIF", but there you have it, raster animation in GIF format, that could easily be replaced with APNG.

Also, I was talking about forums when I mentioned places that don't accept video upload. GIFs are popular in forums.

I hope I made myself clear now. Regards.

Comment 64 by, Aug 13 2010

"There seems to be quite a bit of FUD about SVG+SMIL here. First off, no, a simple transparent animated loading throbber does not use that much of your CPU at 18x18px (which seems like a reasonable size for a loading throbber)."

> I'm creating an HTML5 web application.  There are a number of places where animation enhances the interaction with the user (e.g. buttons with an interior icon that spins to indicate motion, progress bars etc).  I realize that there are many ways to accomplish similar functionality.  I would like to use APNG.  The animation is fluid, transparency is taken into account, file size is reasonable.  I'm not going to use Flash, Video, or animated Gifs.  I am using SVG+SMIL.  I am running on a dual core PC with 4 gigs of ram.  When one of these SVGs loads, I notice CPU spikes.  When multiple SVGs are loaded the user interface sputters.

Sure, if all you want is an 18X18 throbber, then have at it (I'm using svg for that too BTW), but for those of us that want to create dynamic content that runs smoothly and isn't relying on a 3rd party plugin like Flash ... give us APNG.

Comment 65 by, Aug 13 2010

Yeah, I'm not against APNG or anything. I'm just trying to state that for simple webapps with only maybe 2 simple animations, SVG+SMIL is great. APNG definitely has its use for your site I'm assuming. It's a shame that there's no low-overhead video formats supported by browsers with an alpha channel.

Comment 66 by, Aug 14 2010

It's worth noting that APNG is also a lossless format, which theora and h264 aren't. For images with few frames, it's a big advantage.

Comment 67 by, Sep 24 2010

Chrome actually has a PROBLEM even with the first frame of apngs. No other browser does.

It sometimes fails to display the apng at all when it is embedded in page, but displays it if they are opened in their own tab. I guess there is some heuristics detecting the .png file as invalid and it is failing! It happens especially for longer animations...

Comment 68 by, Nov 18 2010

Everyone keeps spouting about video formats -- APNG is supposed to compete with GIF as an animation format, it's not for video! Also, even if it was, none of the video formats have an alpha channel.

Everyone also keeps going on about SVG -- blah, apples-to-oranges, SVG is for vectors, APNG for bitmap. No more.

Everyone also keeps saying stuff about JavaScript -- like has already been said, only on sites you own is this even possible. For posting a picture on a forum, you can't do this. Or any of the other options. You're stuck with GIF in that case.

Lastly, MNG is... well... unsupported by everything. It's dead and gone.

Go for APNG!

Comment 69 Deleted

Comment 70 by, Nov 20 2010

My vote as well. As the owner of multiple forums, APNG would enhance the user experience significantly.

Comment 71 by Deleted ...@, Nov 21 2010

I use apng all the time. (with the "skip first frame" option, and in the first frame I put a "Get Firefox to view this" button) I love apng, and I fully support what gnarkol's said. Don't be so anal about it, just implant the damn thing. :P

Comment 72 by, Nov 21 2010

APNG could bridge the time gap until AWebP comes into play. ;-)

Comment 73 by, Nov 21 2010

You mean WebM?

Comment 74 Deleted

Comment 75 Deleted

Comment 76 by, Jan 31 2011

 Issue 71383  has been merged into this issue.

Comment 77 by, Feb 12 2011

 Issue 72798  has been merged into this issue.

Comment 78 by, Feb 26 2011

 Issue 74248  has been merged into this issue.

Comment 79 by, Mar 12 2011

 Issue 75805  has been merged into this issue.

Comment 80 by, Oct 25 2011

 Issue 101460  has been merged into this issue.

Comment 81 Deleted

Comment 82 by, Aug 30 2012

 Issue 145313  has been merged into this issue.

Comment 83 by, Jan 10 2013

 Issue 169273  has been merged into this issue.

Comment 84 Deleted

Comment 85 Deleted

Comment 86 Deleted

Comment 87 by, Oct 25 2013

 Issue 311451  has been merged into this issue.

Comment 88 by, Oct 25 2013

 Issue 311451  has been merged into this issue.

Comment 89 by, Oct 25 2013

 Issue 311451  has been merged into this issue.

Comment 90 by, Nov 25 2013

 Issue 323007  has been merged into this issue.

Comment 91 by, May 3 2014

 Issue 369809  has been merged into this issue.

Comment 92 by, Oct 25 2014

 Issue 424842  has been merged into this issue.

Comment 93 by, Oct 26 2014

 Issue 424842  has been merged into this issue.

Comment 94 by, Oct 27 2014

 Issue 424842  has been merged into this issue.

Comment 95 by, Feb 13 2015

Labels: -Cr-Blink Cr-Blink-Image

Comment 96 by, Apr 13 2015

 Issue 476036  has been merged into this issue.

Comment 97 by, Apr 13 2015

 Issue 437662  has been merged into this issue.

Comment 98 Deleted

Comment 99 by, Jun 16 2016

Labels: -Hotlist-OpenBugWithCL

Comment 100 by, Jun 30 2016

 Issue 437662  has been merged into this issue.

Comment 101 by, Jul 4 2016

Labels: Hotlist-Interop
With Safari and Firefox supporting APNG, it may be surprising to developers that Chrome does not.  Adding Hotlist-Interop.

Comment 102 by, Jul 8 2016

Note that someone was maintaining a patch in  Issue 437662 :

Comment 103 by, Jul 20 2016


Comment 104 by, Jul 21 2016


Comment 105 by, Oct 11 2016

Mergedinto: 437662
Status: Duplicate (was: Available)

Comment 106 by, Mar 14 2017

Project Member
The following revision refers to this bug:

commit 7d2b8c45afc9c0230410011293cc2e1dbb8943a7
Author: scroggo <>
Date: Tue Mar 14 21:36:44 2017

Add support for Animated PNG

Update the browser accept header to state that APNG is supported. Split
the decoding of PNG images into two stages: parsing and decoding. During
parsing, chunks are handled one of three ways:
- acTL and fcTL chunks, which specify properties of an APNG are read and
the properties are stored. If they contain an error before IDAT, the image
is treated as a static PNG, as recommended by the spec [1]. If they contain
an error after IDAT, this is a failure, since some frames may have been
decoded. CRCs are calculated and compared to their expected values.
Mismatches are considered errors.
- fdAT and IDAT chunks have their locations stored for decoding later. Any
ordering violations result in either a static image or failed image,
depending on whether IDAT has been seen yet.
- Other chunks before IDAT are passed to libpng for processing.

Each frame is decoded as if it were a complete PNG file. fdATs are converted
to IDATs (and their CRCs are ignored**) and the IHDR is modified for subset
frames. The rowAvailable callback positions subset frames properly within the
full image buffer. For a static PNG or the first frame decoded (assuming its
size matches IHDR) the png struct used during parsing is reused. Otherwise,
a new png struct is created for the duration of the decode.

Follow the APNG spec as closely as possible and use the APNG test page [2] as
a guide for intended behavior. All of the valid APNG on the test page work
as expected. For the invalid APNG:
- Errors that occur before IDAT show the default image, as intended
- Errors afterwards are typically treated as failures (see Future work, below)
- The final three images draw incorrectly. They have incorrectly sized IDATs/
fdATs. These could be respected by checking the warning that libpng sends
(in the case of extra data) or keeping track of how many rows have been seen
(in the case of too little data), although we currently ignore this for static
PNGs anyway. (

The first frame can be decoded progressively. Other frames are not reported
until the following fcTL chunk has been reached during parse.

Add a reference test, modified from WebKit's fast/images/animated-png.html
with the following changes:
- use window.internals.advanceImageAnimation instead of waiting for a
timeout, for more reliable testing
- disable two of the images, which look the same to my eyes, but are not
identical (I suspect due to blending differences as compared to how the
reference tests were created).

Add gtests. Update progressive tests to reuse a SharedBuffer, rather than
recreating it, to reduce test run-time.

Fix a bug in ImageFrameGenerator where it called setMemoryAllocator before
setting the data, and add related tests.

Stop calling setFailed inside ImageDecoder::initFrameBuffer, return false
instead. Clients are now expected to call setFailed (update the WEBP and
GIF clients). This is safer, because setFailed may delete an object that
called initFrameBuffer.

In WEBPImageDecoder: rename frameIsLoadedAtIndex to frameIsReceivedAtIndex,
for consistency with PNGImageDecoder.

Always call ImageFrame::setStatus last (e.g. after calling onInitFrameBuffer,

Future work:
- Revert to showing the default image for failures past IDAT. This is tricky,
since the client may be holding on to previous frames, and we need to make
sure they switch to using the IDAT frame, even if it is not part of the
animation. For now, we mark the decoder as having failed. (

** We cannot allow libpng to check the CRC since we modified the chunk. We
could check the CRC directly as a separate step.


BUG= 1171  BUG= 437662 

Initial patch is a re-upload of issue 2386453003 at patchset 39
( by, which
also used by
as a reference.

Cr-Commit-Position: refs/heads/master@{#456840}

Showing comments 7 - 106 of 106 Older

Sign in to add a comment