Intent to Implement: Animated PNG

[Max Stepin]

Contact emails maxs...@gmail.com Spec https://wiki.mozilla.org/APNG_Specification Summary Support for animated PNG images. Motivation 256-color GIF still serves as the Web's lowest common denominator for simple animations, since it works everywhere. But APNG already works in Firefox and Safari/WebKit, so why not add blink-based browsers into the equation and agree on something better than obsolete 256-color format from the 80s? Compatibility Risk Firefox: Shipped Safari: Shipped Internet Explorer: Public skepticism Web developers: Positive Describe the degree of compatibility risk you believe this change poses Mature, stable specification. Support is other browsers. Low risk. Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes OWP launch tracking bug http://crbug.com/437662 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/6691520493125632 Requesting approval to ship? No

[michal.go...@laboratorium.ee]

Shouldn't IE be changed in these intents to Edge? IE is never changing anymore.

[seb mitchell]

I am just an end user of chrome, but here is my 2 cents, etc.

Just a historical note, we had mng, an animated format from png people, used on firefox and Japanese mobiles in the 90s, then removed from firefox/killed by mozilla.

https://bugzilla.mozilla.org/show_bug.cgi?id=18574

After 15 years I think we need to move on from apng, is that direction webp or something els

[Eric Bidelman]

Michal, we're updating "IE" -> "Edge" in https://github.com/GoogleChrome/chromium-dashboard/issues/217

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Max Stepin]

Edge.devs told me they don't have plans for additional formats "at this time", thus "public skepticism":

https://twitter.com/MSEdgeDev/status/596197829414035456

A few technical details about proposed implementation (which is almost finished) :

First frame is a normal PNG (for backwards compatibility), and the other frames are stored in a similar fashion, so it's easy to remux them into regular PNG and send them to libpng for decoding:

There is no need for additional libraries, libpng is sufficient, and a lot of existing code in PNGImageDecoder.cpp can be reused for all frames, not just the first: headerAvailable(). rowAvailable() etc. There is still a new code required for remuxing, so new PNGImageDecoder.cpp will be 300-350 lines longer.

[PhistucK]

Did you get any sense of approval regarding adding this feature? If not, writing code for it is a bit of wasting your time...

☆PhistucK

[Peter Kasting]

This has been explicitly refused for inclusion in Blink repeatedly.  What's changed to lead to proposing it again?

PK

[Paweł Hajdan, Jr.]

Shouldn't https://code.google.com/p/chromium/issues/detail?id=1171 be closed as WontFix then? The bug being opened might suggest it's just waiting for someone to implement it.

Paweł

[Max Stepin]

Not yet. That's why I'm posing this here. I was hoping that looking at the actual working code might help to restart this discussion. I'm just following the launch process procedure:  1. adding an entry on chromestatus.com  2. filing an OWP launch tracking bug  3. sending an "Intent to Implement" to blink-dev. But if I'm doing this incorrectly, let me know.

We never discussed the actual technical issues of animated png format, and this seems to be a good place. Having a simple working implementation might affect the decision, I hope. Since our last talk, APNG support landed in Safari/WebKit and more recently in ffmpeg.

Another technical detail I wanted to clarify: the diagram above shows how frames can be converted into PNGs. But that doesn't mean they all have to be full-size PNGs. Rectangles for other frames can be smaller (dimensions are stored in fcTL) and transparency can be used to store only deltas between frames, so inter-frame optimization is possible. An example here: http://littlesvr.ca/apng//inter-frame.html

And here's the code, please take a look:
https://codereview.chromium.org/1250373006/

[PhistucK]

But those technical issues were not the reasons not to support it, as far as I remember. It was a broader conceptual issue.

☆PhistucK

[Max Stepin]

Still, technical complexity should be a factor in the discussion, I hope.

Based on the guidelines here, http://www.chromium.org/blink#TOC-Policy-for-shipping-and-removing-web-platform-API-features  there are 4 cases and I think apng falls into the first one, since it's both low compatibility risk and moves the web forward..

Quote from that link:

Balancing "moving the web forward" and "compatibility risk"

Blink's willingness to accept a change is largely determined by the change's location on the chart above:

If a change has low compatibility risk and significantly moves the web forward, Blink usually welcomes it (e.g., shipping unprefixed CSS Transforms).
If a change has low compatibility risk but isn't expected to significantly move the web forward, Blink usually still welcomes it. Occasionally, Blink will reject changes in this bucket to avoid technical complexity (e.g., not shipping our old implementation of CSS Variables).
If a change has high compatibility risk and isn't expected to significantly move the web forward, Blink will usually not welcome it (e.g., not shipping canvas supportsContext).
If a change has high compatibility risk but is expected to significantly move the web forward, Blink will sometimes welcome it after careful, publicly-explained consideration (e.g. shipping Shadow DOM).

I

[PhistucK]

It is very simple to add a constant "foo" property on Window, with the value of "bar". That does not mean it is a factor. On the other hand, if it is complex, it is a factor not to let it in. I would say that the technical complexity is a serious factor against a feature, while the technical simplicity is much less of a factor for a feature.

Regarding whether it moves the web forward, this is a very subjective question, to which you answer "yes" while most of the rest (here) answer "no".

☆PhistucK

[Max Stepin]

So you're saying it's most likely a second of the four cases? This one:

If a change has low compatibility risk but isn't expected to significantly move the web forward, Blink usually still welcomes it. Occasionally, Blink will reject changes in this bucket to avoid technical complexity

But that means "Blink usually still welcomes it" unless it's too complex.

I still think that having Chrome/Opera/Firefox/Safari agree on one format (leaving only IE/Edge out) would be a significant step forward for the users.

[Philip Jägenstedt]

On Mon, Aug 3, 2015 at 1:11 PM, Max Stepin <maxs...@gmail.com> wrote:

So you're saying it's most likely a second of the four cases? This one:

If a change has low compatibility risk but isn't expected to significantly move the web forward, Blink usually still welcomes it. Occasionally, Blink will reject changes in this bucket to avoid technical complexity

But that means "Blink usually still welcomes it" unless it's too complex.

I still think that having Chrome/Opera/Firefox/Safari agree on one format (leaving only IE/Edge out) would be a significant step forward for the users.

Opera 12 (based on Presto) seems to support APNG, but current versions of Opera are based on Chromium and thus do not support APNG.

Some earlier threads:

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/2xvXNJMsgxc/2CJ9jl-jItcJ

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/GST5on0-3ykJ

Urvang, did anything happen with animated WebP after that thread?

Philip

[PhistucK]

Animated WebP is supported.

http://littlesvr.ca/apng/images/GenevaDrive.webp

☆PhistucK

[Peter Kasting]

On Mon, Aug 3, 2015 at 4:11 AM, Max Stepin <maxs...@gmail.com> wrote:

So you're saying it's most likely a second of the four cases? This one:

If a change has low compatibility risk but isn't expected to significantly move the web forward, Blink usually still welcomes it. Occasionally, Blink will reject changes in this bucket to avoid technical complexity

But that means "Blink usually still welcomes it" unless it's too complex.

I still think that having Chrome/Opera/Firefox/Safari agree on one format (leaving only IE/Edge out) would be a significant step forward for the users.

I don't make the final call here, but I'll reiterate the concerns I think have been expressed before:

* With animated WebP, it seems like Chromium supports a format that's basically a superset of the capabilities of APNG already, for authors willing to encode for formats not supported by all browsers

* For other authors, APNG doesn't help unless IE/Edge are going to support

* There seems to be comparatively little web author interest in APNG (even taking into account its limited cross-browser support in the past), so relatively little upside to this

* The additional implementation in the PNG image decoder source is reasonably complex

PK 

[Chris Blume]

As I understand it, Mozilla is implementing WebP support.
Neither APNG nor WebP are supported by IE/Edge.
There is a mix between Safari and Opera. Opera supports WebP. Safari supports APNG. Earlier in this email thread there was mention that Opera 12 supported APNG but I believe it was actually removed after Opera 12.

If the Chromium developers added APNG support, web developers would still have to check for support and fallback to something else. So to the web developer, APNG isn't buying them much.

Also as I understand it, WebP gives better compression most of the time for roughly-equivalent image quality. I believe letting Mozilla complete WebP support is the better option. Once Mozilla finishes, I don't see much benefit at all to adding APNG support.

If Chromium developers were to start adding APNG support and finish before Mozilla added WebP support then there is a short-term gain at the cost of more formats to support/maintain. I'm not sure that short-term gain is worth it.


The type of inter-frame compression supported by APNG is fairly basic. It doesn't offer much room for compression. Essentially, it is just decoding a smaller image if it can. However, many animated gifs I see today (anecdata, I know) involve full-frame updates.



I am listening and receptive to adding APNG support. These are my current thoughts. I am happy to hear if there may be points I have missed that support APNG.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Brandon Jones]

I'm fairly agnostic regarding APNG support, but I was excited to hear that Mozilla was implementing WebP. Unfortunately the bug that was linked doesn't give me much hope. Comments got locked over a year ago due to non-productive bickering and the patches attached to the bug are two years old. Do we have any more recent indication that it's something Mozilla is seriously considering?

[PhistucK]

On Tue, Aug 4, 2015 at 12:07 AM, Chris Blume <cbl...@google.com> wrote:

As I understand it, Mozilla is implementing WebP support.

It is a very long page - can you point to the comment (or anything else) that makes you understand that they are implementing it? The status is "New". and there are a bunch​ of redundant user comments.

☆PhistucK

[Max Stepin]

I don't make the final call here, but I'll reiterate the concerns I think have been expressed before:

* With animated WebP, it seems like Chromium supports a format that's basically a superset of the capabilities of APNG already, for authors willing to encode for formats not supported by all browsers

And yet people keep on making and posting APNG files:

http://apngden.tumblr.com

 

* For other authors, APNG doesn't help unless IE/Edge are going to support

IE/Edge won't be able to withstand public pressure, being the only browser without APNG, not for long.
APNG support is already in Top 20 most requested features for Edge, with 2400 votes:
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/filters/top

It's in Top 20 for chromium too, btw:
https://code.google.com/p/chromium/issues/list?sort=-stars&groupby=&colspec=Stars+ID+Pri+Mstone+Status+Owner+Summary

* There seems to be comparatively little web author interest in APNG (even taking into account its limited cross-browser support in the past), so relatively little upside to this

There are lots of user-generated content already, just searching for apng on http://deviantart.com gives 810 results, searching on http://www.pixiv.net and https://www.tumblr.com gives more. Artists aren't happy with 256-color GIF limitations and they are willing to experiment and try new things.

Authoring tools are also reasonably popular, judging by download stats:

https://sourceforge.net/projects/apngasm/files/stats/timeline?dates=2015-01-01+to+2015-07-31
https://sourceforge.net/projects/gif2apng/files/stats/timeline?dates=2015-01-01+to+2015-07-31
 

* The additional implementation in the PNG image decoder source is reasonably complex

Yes, it adds a bit of additional complexity, but at 300-350 new lines it's manageable. And there are tests.

[Anne van Kesteren]

On Mon, Aug 3, 2015 at 11:07 PM, 'Chris Blume' via blink-dev
<blin...@chromium.org> wrote:
> As I understand it, Mozilla is implementing WebP support.
> Neither APNG nor WebP are supported by IE/Edge.
> There is a mix between Safari and Opera. Opera supports WebP. Safari
> supports APNG. Earlier in this email thread there was mention that Opera 12
> supported APNG but I believe it was actually removed after Opera 12.

Well yes, because Opera then became the same as Chrome. Any decision
made here will also be picked up by Opera. Doesn't seem fair to
consider that separately. That makes the only other holdout Edge, and
as we've seen with countless technologies, they'll play ball if
everyone else is.


--
https://annevankesteren.nl/

[seb mitchell]

I just checked and there are 200 more votes for edge to support webp than apng.

To me looking back, seems ripping the mng format out of firefox and replacing it the mozilla apng format may have

cause the lack of general adoption of an animated png format and all those user who invested time into the mng format lost out.

In hindsight it may have be more productive to improve mng instead of creating apng.

More ramblings

Mozilla did not put the mng format back in, after 1000s votes to do so, and so I see they are unlikley to implement anything that completes with apng, like webp.

I am just an end user, I assume there are lots of things mozilla and google agree on and some thing that google would have like to have seen in firefox. 

Maybe it is google view is that apng does not help in moving the web forward, a lot has changed in 15 years, maybe it is time to move on from apng.

[Peter Kasting]

On Mon, Aug 3, 2015 at 11:21 PM, Max Stepin <maxs...@gmail.com> wrote:

I don't make the final call here, but I'll reiterate the concerns I think have been expressed before:

* With animated WebP, it seems like Chromium supports a format that's basically a superset of the capabilities of APNG already, for authors willing to encode for formats not supported by all browsers

And yet people keep on making and posting APNG files:

http://apngden.tumblr.com

I'm not denying APNG exists.  I'm denying that there's comparatively large web author demand for it.

* For other authors, APNG doesn't help unless IE/Edge are going to support

IE/Edge won't be able to withstand public pressure, being the only browser without APNG, not for long.

They will if, like us, they believe that there's a lot of noise being generated by a small number of people and the rest of the world doesn't care.

I'm reminded of MNG, where a small number of people (thousands is a small number) made a huge amount of noise on various bugs but the actual real-world demand for the feature was low and its cost/benefit tradeoffs didn't make sense.

 

Searching for apng on http://deviantart.com gives 810 results, searching on http://www.pixiv.net and https://www.tumblr.com gives more. Artists aren't happy with 256-color GIF limitations and they are willing to experiment and try new things.

That sounds like basically nothing.  Hundreds of thousands of images would be more interesting.

As I said before, authors truly unhappy with GIF limitations who are willing to "try new things" already have an option in Chrome that is monotonically better than APNG.  Comparatively few use it, and I think the reasons why also apply to APNG.

PK

[Max Stepin]

On Tuesday, August 4, 2015 at 10:03:58 PM UTC+3, Peter Kasting wrote:

 

That sounds like basically nothing.  Hundreds of thousands of images would be more interesting.

But that's still like 100 animated png for every 1 animated webp, right?
 

As I said before, authors truly unhappy with GIF limitations who are willing to "try new things" already have an option in Chrome that is monotonically better than APNG.  Comparatively few use it, and I think the reasons why also apply to APNG.

 
They are not exercising that option. I don't see artists creating animated webp files, at all.

The numbers are probably in single digits.
 

[Chris Blume]

Keep in mind that other larger organizations such as Facebook and Netflix are using WebP. They alone surely provide far more WebP images than you will find APNG images.

I think we should not be making policy decisions involving future supported formats based on guessed current usage. Let's try to keep this as scientific as we can.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Max Stepin]

Keep in mind that other larger organizations such as Facebook and Netflix are using WebP.

They are not using animated WebP though.

[Elliott Sprehn]

Does mobile Safari support APNG today?

[Mike Lawther]

http://caniuse.com/#feat=apng says yes (8.4 and 9.0).

[Rik Cabanier]

The demos from https://people.mozilla.org/~dolske/apng/demo.html work as expected on my iPhone.

[Noel Gordon]

Perhaps run the demos for a while to see how well your battery lasts.  No data on that aspect (battery use) in this thread that I can find.

Proposing an RGBA-based format is interesting noting that YUV encoded still and motion image formats appear to rule our world. Chrome mobile supports YUV decoding on the GPU. That might improve battery use, but it certainly leads to faster decoding and reduces memory use.

Best I can tell, APNG is an RGBA-based format that requires CPU decoding. And PNG is the slowest image decoder we have (the most CPU intensive for the same image w x h).  I have no data, but I expect that battery use will be impacted.

~noel

[Rik Cabanier]

On Wed, Aug 5, 2015 at 9:54 PM, Noel Gordon <no...@chromium.org> wrote:

Perhaps run the demos for a while to see how well your battery lasts.  No data on that aspect (battery use) in this thread that I can find.

Proposing an RGBA-based format is interesting noting that YUV encoded still and motion image formats appear to rule our world. Chrome mobile supports YUV decoding on the GPU. That might improve battery use, but it certainly leads to faster decoding and reduces memory use.

Can you explain why this is? It seems that not having to do an extra yuv -> rgb step would reduce work and increase battery life.

 

Best I can tell, APNG is an RGBA-based format that requires CPU decoding. And PNG is the slowest image decoder we have (the most CPU intensive for the same image w x h).  I have no data, but I expect that battery use will be impacted.

Maybe we can ask Apple since they focus a lot on increasing battery life

[Max Stepin]

On Thursday, August 6, 2015 at 7:55:05 AM UTC+3, Noel Gordon wrote:

Proposing an RGBA-based format is interesting noting that YUV encoded still and motion image formats appear to rule our world. Chrome mobile supports YUV decoding on the GPU. That might improve battery use, but it certainly leads to faster decoding and reduces memory use.

I don't see any kind of GPU acceleration code in image-decoders folder.

For example, take a look at outputRows() in JPEGImageDecoder.cpp

Does the inner loop looks optimal, with 3 multiplications and 3 divisions per pixel?

[Noel Gordon]

On 6 August 2015 at 15:44, Rik Cabanier <caba...@gmail.com> wrote:

On Wed, Aug 5, 2015 at 9:54 PM, Noel Gordon <no...@chromium.org> wrote:

Perhaps run the demos for a while to see how well your battery lasts.  No data on that aspect (battery use) in this thread that I can find.

Proposing an RGBA-based format is interesting noting that YUV encoded still and motion image formats appear to rule our world. Chrome mobile supports YUV decoding on the GPU. That might improve battery use, but it certainly leads to faster decoding and reduces memory use.

Can you explain why this is? It seems that not having to do an extra yuv -> rgb step would reduce work and increase battery life.

I too would expect that doing the yuv->rgb step on the GPU reduces work and increases battery life.  But I have no data on that, so I said "might".

Best I can tell, APNG is an RGBA-based format that requires CPU decoding. And PNG is the slowest image decoder we have (the most CPU intensive for the same image w x h).  I have no data, but I expect that battery use will be impacted.

Maybe we can ask Apple since they focus a lot on increasing battery life

 

Maybe.  A keen focus on conserving battery life there (with which I agree, btw), yet an image format that seems to do the exact opposite.

~noel

[Noel Gordon]

What JPEG formats are decoded by outputRows()?  Compare with how YUV JPEG are decoded (m_imagePlanes, in particular).

~noel

[Max Stepin]

OK, but I still don't see GPU acceleration anywhere in image-decoders.

PNGs are used a lot because there are plenty of use cases where JPEG and JPEG-like formats simply aren't suitable.

Not every image is a photo.

[Mike Lawther]

On 6 August 2015 at 15:44, Rik Cabanier <caba...@gmail.com> wrote:

Maybe we can ask Apple since they focus a lot on increasing battery life

I understand that Safari uses closed source PNG decoders. This is why we saw APNG support in Safari before it landed in WebKit. 

[piotr.jerzy...@gmail.com]

Also as I understand it, WebP gives better compression most of the time for roughly-equivalent image quality. I believe letting Mozilla complete WebP support is the better option. Once Mozilla finishes, I don't see much benefit at all to adding APNG support.

Do you have any research to back up this assumption?

According to this comparison study, APNG files are smaller than WebP: http://littlesvr.ca/apng/gif_apng_webp.html

[Chris Blume]

I do not think the images sampled on that page are a fair representation what you would see as common animated images on the web right now. I am happy to listen openly if you feel differently.

Those images happen to be images that afford APNG several benefits. For example, there are no full-frame updates.

To try to be a tad more fair, I went to imgur and looked for the first animated gif I could find. Check out http://imgur.com/gallery/QyCAM. The second image, with the text "Engage" is an animated gif.

I used the same tools they suggested in http://littlesvr.ca/apng/gif_apng_webp.html (gif2apng and gif2webp).


Original gif: 996 KiB
APNG: 798 KiB
WebP: 787 KiB
Lossy WebP: 133 KiB



I don't mean to suggest APNG has no benefits. It is quite ideal for situations where you do not have full-frame updates or the content is more of an icon than a video. It is better than WebP in those situations.

But please test for yourself on the content you are interested in.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Blume]

Oh and as far as research to back up the claim, there are both lossless vs. png and lossy vs. jpeg comparisons. The lossless vs. png comparison is for non-animated content, however.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

[Max Stepin]

On Sunday, August 23, 2015 at 4:49:22 AM UTC+3, Chris Blume wrote:

I do not think the images sampled on that page are a fair representation what you would see as common animated images on the web right now. I am happy to listen openly if you feel differently.

I think it's always more fair to represent different types on content. Picking just one would be less fair.

And that page represents different types of GIFs, not just 2-seconds-cut-from-a-movie GIFs, but also diagrams from wikipedia, and a cartoonish "doodle".

 

Those images happen to be images that afford APNG several benefits. For example, there are no full-frame updates.

I'm not sure what you mean by that. All those formats are capable of utilizing full frames, as well as inter-frame optimizations. I don't see any unfair benefits to APNG here. Using keyframes or not, it's up to authoring tools, anyway.
 

To try to be a tad more fair, I went to imgur and looked for the first animated gif I could find. Check out http://imgur.com/gallery/QyCAM. The second image, with the text "Engage" is an animated gif.

Choosing a random GIF from Imgur is not a best way of doing it, since Imgur converts longer GIFs into videos. That's why only the short 16-frame "Engage" GIF in that gallery is still a GIF. Ideally, you'd want to avoid such pre-selection filter and use a source that won't mess with the GIF uploads.

I downloaded the first 16 pages from http://iwdrm.tumblr.com/ so now I have a corpus of 110 high-quality GIFs for testing:

GIFs:
55 874 090 bytes
https://drive.google.com/file/d/0B87CElpmcFpPV2VPMkJ0VENlN2s/view

After conversion, here are the results:

Lossless WebP:
72 526 230 bytes
https://drive.google.com/file/d/0B87CElpmcFpPQ0kwMjFiUDhXbE0/view

Lossless WebP, without keyframes:
53 579 128 bytes
https://drive.google.com/file/d/0B87CElpmcFpPenpDOTRDWERVV3M/view

APNG:
49 158 595 bytes
https://drive.google.com/file/d/0B87CElpmcFpPSnpJNzlHcVFqN2M/view

 

I don't mean to suggest APNG has no benefits.

So why not implement it and get the benefits?

Also, I see the Edge devs just marked the request for APNG support as "Under Review" so at least they're thinking about it.

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/filters/top

Max.
 

[Dmitry Azaraev]

Hello.

I'm just chromium user (from first version), but, because I'm developer (mainly not web, but know pain of cross platform web development even only inside android) - I'm take a look on changes or discussions. All you guys, make great work!

But:

1. To move web forward, you need innovations, without respect to ghosty risks. Let me explain on example: every page implement own selectbox with rich content, and it is always works bad. Again - always. Web platform? It is joke. Allow developers show native popups (menus) with custom content, like engine do this, for calendars or date picker. This will increase usability on all valuable platforms. This will move web forward.

2. Web and platform, and browsers, is already technologies. Software technology is kind of software where nor 80/20 nor good enough rules is not enough. Technology should be flexible as it possible by any cost. (In this thread - not so big cost). I'm know that chromium team doing hardly on this. But this discussion just show that some people's just did not want / not sure. So why intents need, if at end decision taken by one person?

3. You worry about universe, while every chromium debug build crash in constantly normal environment: non ASCII chars in mime types on windows (by DCHECK), dchecks in fonts, what are work for peoples for years. Heh. Anyone sure, that there is expected? Okay, it is not in scope of thread. But note, that constant ignoring errors what are work good in production in years - is becomes expected behavior. It is not code critics. It is just shows, that before move web forward, you should close bugs. And BTW some bugs have more than 4 years.

4. While exists few number of major browsers - it automatically means, that others should (not must) implement same things. Otherwise - it is becomes again to web developer pain. And to end users too. If you support APNG - only IE/Edge will be last browser, that not support it. And this looks like that they do it. It is also part of move forward.

Finally - like Max shows, cost of APNG not so bigger, but benefits visible. From me - cost of Oilpan is high, but is mostly visible to developers (it is right direction, if is just for compare). And most users actually no found any difference. Yes, it is also by hard work.

You are speak about only in this thread, about month, about thing what already happens at two major browsers, and choose who will be third - chrome or edge. There is moving web backward.

With love to chromium, and big respect to all of yours big work!

Sincerely,
Dmitry

[Pascal Massimino]

Hi,

On Sunday, August 23, 2015 at 8:21:58 AM UTC-7, Max Stepin wrote:

On Sunday, August 23, 2015 at 4:49:22 AM UTC+3, Chris Blume wrote:

I do not think the images sampled on that page are a fair representation what you would see as common animated images on the web right now. I am happy to listen openly if you feel differently.

I think it's always more fair to represent different types on content. Picking just one would be less fair.

And that page represents different types of GIFs, not just 2-seconds-cut-from-a-movie GIFs, but also diagrams from wikipedia, and a cartoonish "doodle".

 

Those images happen to be images that afford APNG several benefits. For example, there are no full-frame updates.

I'm not sure what you mean by that. All those formats are capable of utilizing full frames, as well as inter-frame optimizations. I don't see any unfair benefits to APNG here. Using keyframes or not, it's up to authoring tools, anyway.

Exactly. And some aspects the apparently surprising sizes for WebP were discussed here:

https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/yo8GRZlvpbo

Namely: while you can squeeze as much size as possible during encoding (gif2webp has a '-min' option for that),

it's also advantageous to insert full-refresh frames at critical positions, in order to reduce browser's memory pressure

at decoding time.

skal/

[Max Stepin]

On Thursday, August 6, 2015 at 7:55:05 AM UTC+3, Noel Gordon wrote:

Perhaps run the demos for a while to see how well your battery lasts.  No data on that aspect (battery use) in this thread that I can find.

 

OK, I ran this demo for a while to collect the stats on 100 000 frames (3/100 sec delay means it took 3000 seconds = 50 minutes):

http://littlesvr.ca/apng/gif_apng_webp1.html

I measured the time spent inside decode(index) call from ImageDecoder::frameBufferAtIndex(size_t index)

Here's the results, total time for each animation:

24.3 sec : GIF
32.8 sec : APNG
34.4 sec : WebP 1
71.0 sec : WebP 2

It's interesting that GIF decoding wins, but maybe it's because the algorithm is more simple. Second place for APNG is not too bad.

But overall, I think none of those formats appears to be a heavy CPU burden. 24-71 seconds out of 50 minutes should not drain the battery.


P.S.
I can't find a way to add Cr-Blink-Image label to my Launch-OWP bug: http://crbug.com/437662
Can someone help be with that? Also, the bug appears to be closed for some reason, any idea why?
 

[Peter Kasting]

On Mon, Aug 24, 2015 at 11:30 PM, Max Stepin <maxs...@gmail.com> wrote:

On Thursday, August 6, 2015 at 7:55:05 AM UTC+3, Noel Gordon wrote:

Perhaps run the demos for a while to see how well your battery lasts.  No data on that aspect (battery use) in this thread that I can find.

 

OK, I ran this demo for a while to collect the stats on 100 000 frames (3/100 sec delay means it took 3000 seconds = 50 minutes):

http://littlesvr.ca/apng/gif_apng_webp1.html

I measured the time spent inside decode(index) call from ImageDecoder::frameBufferAtIndex(size_t index)

Here's the results, total time for each animation:

24.3 sec : GIF
32.8 sec : APNG
34.4 sec : WebP 1
71.0 sec : WebP 2

I know you mean well, but as the GIF decoder owner and someone who's spent extensive time on perf of various decoder formats, these numbers are incredibly misleading.  Decode perf varies wildly by source image, specifically what sort of format features the image uses.  Two identical-appearing GIFs can have wildly different decode perf if one uses GIF's equivalent of keyframes and the other doesn't, depending on how loaded your machine is and what kind of seeking the decoder needs to do (if e.g. you make the image non-visible for a bit and then reshow it in a way that requires a spin-forward).

It also matters what frames the owning display subsystem caches, which depends on a variety of factors.

So the format, the encoder, the system state, and the user behavior while watching all play important roles in measuring perf.  You're simply not going to get a representative numbers by taking any comparison image like this and just running some timings.

We're trying to get good data and discuss things off-thread, please just give us time to do so.

PK

[Philip Jägenstedt]

Has there been any progress on this? We shouldn't stall this intent indefinitely, so some idea about the timeline of the remaining investigation would be useful.

Philip 

[Peter Kasting]

Thanks for bringing this up.  I don't know what the current status is; the decision ultimately gets made above my head.  I'll see if I can get someone to chime in here.

PK 

[Mike Lawther]

Hi everyone,

A quick update on we're were at with this.

We've been having discussions with some folks at Mozilla to make sure that if we go ahead with this, that Chrome and Firefox will be consistent in what we present to web developers. Quite recently Mozilla registered a new MIME type (http://www.iana.org/assignments/media-types/image/vnd.mozilla.apng), and we see how this is used as critically important for APNG. Web developers looking to adopt APNG will need to be able to fall back for browsers that still don't support it, and the last thing we want is for them to have to write yet more UA sniffing code.

    mike

[Yoav Weiss]

Are Mozilla planning to publish APNG as part of their Accept headers? Or is the plan that developers rely on <picture> to perform client-side MIME selection? (Ideally devs would be able to do both, and pick the one that fits their setup best)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Max Stepin]

Mozilla is mostly interested in animated PNG in <picture> with animated GIF fallback.

https://bugzilla.mozilla.org/show_bug.cgi?id=1160200

[wyat...@gmail.com]

Sorry for posting so long after the previous post, but I'd like an update.

Since around four or five years ago (back when I was just a lowly web user) I have been interested in getting proper support for APNG in Chrome/Chromium, mainly for the lack of a 256 color index limit and for the presence of an 8-bit alpha channel. I seem to remember learning about it when I searched for something like 'lossless animation without index' (I knew the word 'lossless' because I had experience with converting videos for my ipod).

I was excited, but then saw that it was only (at the time) supported in Opera and Firefox. At that point, I had both Firefox and Chrome installed on my computer, so I was okay with it. I found a Java-based program to assemble APNG's and got cracking. I've wanted and waited for Chrome to implement a good animated format for a long while, and I think that at the current level of adoption for animated WebP, going with APNG is the only sensible choice. It has very low risk of compatibility issues, and it is now more widespread than it was in 2010 with its adoption in Blink's parent WebKit and in Safari. The only holdout now is Chrome/Chromium, and if support were added without going into a religious war about what the One True GIF Replacement Format is, the entire world could rejoice at the death of Old King GIF.

I have had APNGs on my website for the last two years and a little sign saying 'if you use chrome, you're missing out' on the top of my pages that use them. I want to remove them, but until APNG gets support that can't really happen.

I think that if you give the feature, people will use it. Especially since Chrome is basically the last holdout. (As was said earlier, if everyone else does it then Edge will surely follow).

I would hate to see Edge actually implement APNG before Chrome/Chromium can... Especially since that bug report for APNG support in chromium was opened mere days after the initial public release of Chrome and is still open. A lot of people want it, but want to know that it'll work everywhere important before they go ahead. Chrome is the last important holdout that needs to implement it before Edge does and finishes adoption. Heck, even NetSurf supports APNG now.

[sin...@gmail.com]

Judging from the discussion above, the decision not to include (already finished and reviewed) APNG support is clearly political and has nothing to do with technical merits of the format itself or its implementation by Max. Therefore, it is unlikely that continuing dicussion here will bring any results. The issue needs to be taken to the public and media discussion -- and I'm pretty sure the patch will suddenly get accepted and included in the next release.

 

BTW, who exactly is responsible for deciding whether to include APNG support or not? I haven't heard a single name here yet and it's pretty hard to understand the reasoning of someone you can't even talk to.

OlegM 

[wyat...@gmail.com]

>Judging from the discussion above, the decision not to include (already finished and reviewed) APNG support is clearly political and has nothing to do with technical merits of the format itself or its implementation by Max.

I'd agree, it looks like it's purely a political opposition. Kind of hard to logically explain the opposition when you are given the way to do it on a silver platter and everyone else has it, unless you're trying to push your own competing standard... which you want to pressure everyone else to adopt.
I have no idea who's responsibility it is to get this added - I'd do it myself if it were as simple as anyone walking in and committing code. I _REALLY_ want to see APNG natively supported in chrome/blink, since it is a huge benefit for both users and developers, and it'd be a reason for me to stop pushing for Firefox, which just keeps changing things for the worse and becoming less and less different from chromium and is about to lose the one other bonus it had for me (XUL extensions are SUPER flexible). Hopefully the APNG support would trickle down to non-gecko android browsers as well, and then Microsoft's browsers would be the odd ones out as usual. They'd be sure to play catch-up though.

A name would be greatly appreciated as to who is responsible for adding this. :)

[Peter Kasting]

On Mon, Feb 22, 2016 at 1:35 PM, <wyat...@gmail.com> wrote:

>Judging from the discussion above, the decision not to include (already finished and reviewed) APNG support is clearly political and has nothing to do with technical merits of the format itself or its implementation by Max.

I'd agree, it looks like it's purely a political opposition.

Some of the technical concerns were posted earlier in the thread.

 

it is a huge benefit for both users and developers,

One of the many reasons this hasn't happened yet is that it's not at all clear to us it's a "huge benefit" for those groups.

PK

[sin...@gmail.com]

> Some of the technical concerns were posted earlier in the thread.

All of them were refuted or can't be considered a concern at all unless you are desperately grasping at straws to deny an oppossing and more popular standard's presence in Blink at all costs.

> One of the many reasons this hasn't happened yet is that it's not at all clear to us it's a "huge benefit" for those groups.

There is a load of features in Chrome that neither end-users nor web-developers are even aware of, let alone use - unlike APNG. Features that use more code than the proposed APNG implementation. Why were THEY implemented according to your logic? 

>  it's not at all clear to us

And - again  - who is "us" exactly? You were mentioning some mysterious superiors who decide whether to support a feature or not earlier in the thread - who are they? 

OlegM

[Max Stepin]

Well, I'm cautiously optimistic, after reading this:
https://groups.google.com/d/topic/mozilla.dev.platform/0h_7GpOz1a0/discussion

As for benefits, it's pretty obvious:
https://www.google.com/logos/doodles/2016/valentines-day-2016-5699846440747008-5096695956242432-ror.gif
GIF: 260 212 bytes.
APNG: 212 480 bytes.

Max.

[Peter Kasting]

On Mon, Feb 22, 2016 at 2:48 PM, <sin...@gmail.com> wrote:

> Some of the technical concerns were posted earlier in the thread.

All of them were refuted or can't be considered a concern at all unless you are desperately grasping at straws to deny an oppossing and more popular standard's presence in Blink at all costs.

I don't think this is accurate.  The one person I saw attempt to refute the posted concerns was Max Stepin.  There wasn't general clarity or consensus that the concerns were actually refuted.  For example, regarding usage, he cited several hundred instances on DeviantArt, I noted that hundreds of thousands would be more the "interesting" level, and then there was some tangential discussion about whether WebP met this bar.  Regarding complexity, he stated that it would be "manageable" because it's several hundred lines plus tests.  Several hundred lines of image decoder code is a significant amount of complexity and definitely not something I'd want to take on lightly.

Other posted concerns included e.g. mime types and not writing UA sniffing code.  The only update on that front is that Mozilla has so far not seemed terribly interested in either getting a more generic mime type or in sending headers to reduce the number of cases where UA sniffing is needed; discussions are still ongoing there.

> One of the many reasons this hasn't happened yet is that it's not at all clear to us it's a "huge benefit" for those groups.

There is a load of features in Chrome that neither end-users nor web-developers are even aware of, let alone use - unlike APNG. Features that use more code than the proposed APNG implementation. Why were THEY implemented according to your logic?

This is irrelevant to the topic at hand.  We're discussing APNG, not random other features.  Plus you're begging the question by describing these as features "that neither end-users nor web-developers are even aware of, let alone use ... that use more code".  Especially when you're not going to name specific examples, this isn't a productive line of discussion.

>  it's not at all clear to us

And - again  - who is "us" exactly? You were mentioning some mysterious superiors who decide whether to support a feature or not earlier in the thread - who are they?

The web platform leads.  Membership changes over time.  I don't know if there's a public list.

This is the correct mailing list/thread for discussing this and the right people are reading it.  I'm not clear on why calling out names is necessary.  It would be inappropriate to try to personally escalate to some individual, which is the only thing I can see such a name being used for.

PK

[Dexter]

> Regarding complexity, he stated that it would be "manageable" because it's several hundred lines plus tests.  Several hundred lines of image decoder code is a significant amount of complexity and definitely not something I'd want to take on lightly.

I will let Max comment on that since he is the author of the code and Noel Gordon since he is the one who reviewed it. I want to underline, however, the fact that the patch was already accepted and only waits for approval to be included in the release.

> For example, regarding usage, he cited several hundred instances on DeviantArt.

You are inversing the cause-effect relation. Current usage should not be a reason for inclusion of an open standard at all - it's obvious that people will not use APNG extensively until it is supported by Chrome. Neither will they use WebP however, since it's not supported by other browsers, so we are left with the clearly outdated GIF or MP4 (e.g. VK.com converts GIFs to MP4 videos) which is a no-no for being propritary and patent-encumbered. The only compromise here would be to support both WebP and APNG and see who wins - though it's definitely possible that both will be used for different images/uses and I don't see an issue in that. If one standard gets the clear upper hand in future, removing support for the other shouldn't be a problem. Also worth reiterating that even with current limited browser support for both WebP and APNG, APNG clearly is used more often - i.e. there is more demand for it.

> The web platform leads.  Membership changes over time.  I don't know if there's a public list.

Thank for this much at least.

OlegM

[sin...@gmail.com]

Also, since the feature is already implemented, isn't a new e-mail with "Intent to Ship" in order according to your guidelines at http://www.chromium.org/blink#launch-process ? 

OlegM

On Sunday, August 2, 2015 at 8:57:37 PM UTC+3, Max Stepin wrote:

Contact emails maxs...@gmail.com Spec https://wiki.mozilla.org/APNG_Specification Summary Support for animated PNG images. Motivation 256-color GIF still serves as the Web's lowest common denominator for simple animations, since it works everywhere. But APNG already works in Firefox and Safari/WebKit, so why not add blink-based browsers into the equation and agree on something better than obsolete 256-color format from the 80s? Compatibility Risk Firefox: Shipped Safari: Shipped Internet Explorer: Public skepticism Web developers: Positive Describe the degree of compatibility risk you believe this change poses Mature, stable specification. Support is other browsers. Low risk. Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes OWP launch tracking bug http://crbug.com/437662 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/6691520493125632 Requesting approval to ship? No

[Max Stepin]

On Tuesday, February 23, 2016 at 2:02:27 AM UTC+3, Peter Kasting wrote:

This is irrelevant to the topic at hand.  We're discussing APNG, not random other features.  Plus you're begging the question by describing these as features "that neither end-users nor web-developers are even aware of, let alone use ... that use more code".  Especially when you're not going to name specific examples, this isn't a productive line of discussion.

Animated WebP would be a good specific example - web-developers never requested it, almost nobody knows about it, and there are no such files in the wild. SMIL is deprecated due to low usage, why not this one? I guess no one will deprecate the feature if no one knows about the feature. It's too obscure even for that...

Pale Moon browser just added WebP support, but only static, they don't see the point of supporting animated files if they do not exist in the wild.

 

Several hundred lines of image decoder code is a significant amount of complexity and definitely not something I'd want to take on lightly.

 

And how many thousand lines of code spent on supporting animated WebP? Is that not complexity?

For APNG, there is no need to add any libraries into "third-party", it works fine on top of regular libpng. It's very lightweight.

Max.

[seb mitchell]

For APNG, there is no need to add any libraries into "third-party", it works fine on top of regular libpng. It's very lightweight.

Max.

Max I bring up the poor treatment of the mng format by Mozilla again,

maybe it time to move on from apng.

Up to 2003 Firefox had support for the mng format, people were happy using it, but Mozilla they wanted to created their onwn apng format.

They removed the maintained libpng that supported mng, and ended up with security issues. 

Last post in https://bugzilla.mozilla.org/show_bug.cgi?id=195280 

"Disappointing we're getting APNG support instead of MNG just to save a few KB"

[Peter Kasting]

On Mon, Feb 22, 2016 at 3:33 PM, Dexter <sin...@gmail.com> wrote:

> Regarding complexity, he stated that it would be "manageable" because it's several hundred lines plus tests.  Several hundred lines of image decoder code is a significant amount of complexity and definitely not something I'd want to take on lightly.

I will let Max comment on that since he is the author of the code and Noel Gordon since he is the one who reviewed it. I want to underline, however, the fact that the patch was already accepted and only waits for approval to be included in the release.

It's had an initial review, but I don't think it's had a security review, fuzzers written and tested, etc.  And the initial code review is far from the only burden of carrying code in the codebase.

 

> For example, regarding usage, he cited several hundred instances on DeviantArt.

You are inversing the cause-effect relation. Current usage should not be a reason for inclusion of an open standard at all

Which is to some degree what was stated above.  I debated including this, since it's less "a blocker" than "an illustrative example that it's not the case that everything everyone mentioned has been soundly debunked".

 

Neither will they use WebP however,

As stated previously, WebP has seen significant adoption, even though it's not universally supported.  Animated WebP may not be in the same position, but since Chrome-only support wasn't a barrier to non-animated WebP, the conclusion I reach is that the issue for both animated WebP and APNG is not that they're not universally supported, but more that there's relatively niche interest in them.

The majority of GIFs on the web today really ought to be videos, not images.  There are technical reasons why that's challenging for Chromium's rendering pipeline (trying to instantiate dozens of simultaneous videos causes bad things), but to me that's the world we should get to.

we are left with the clearly outdated GIF or MP4 (e.g. VK.com converts GIFs to MP4 videos) which is a no-no for being propritary and patent-encumbered.

There are more options than H.264 etc. for video, e.g. WebM.

 

The only compromise here would be to support both WebP and APNG and see who wins

Or support neither.  Which is a position I personally wouldn't mind taking.  But, as stated before, I don't make the decisions here.  I'm simply trying to clarify.

 

worth reiterating that even with current limited browser support for both WebP and APNG, APNG clearly is used more often - i.e. there is more demand for it.

To exaggerate, ten people using something compared to two is irrelevant at web scale.  Neither animated WebP nor APNG have enough usage to round to anything other than zero.  I don't think there's statistical significance in concluding that one is in more demand than the other; neither is terribly in demand.

PK

[Peter Kasting]

On Mon, Feb 22, 2016 at 6:19 PM, Peter Kasting <pkas...@google.com> wrote:

On Mon, Feb 22, 2016 at 3:33 PM, Dexter <sin...@gmail.com> wrote:

> Regarding complexity, he stated that it would be "manageable" because it's several hundred lines plus tests.  Several hundred lines of image decoder code is a significant amount of complexity and definitely not something I'd want to take on lightly.

I will let Max comment on that since he is the author of the code and Noel Gordon since he is the one who reviewed it. I want to underline, however, the fact that the patch was already accepted and only waits for approval to be included in the release.

It's had an initial review,

Wait, I'm not even sure this is true.  I found two patch variants, a newer one and a superseded older one, and neither had been reviewed, just assigned a reviewer.  Did I miss the actual LGTM'd patch?

PK 

[Dexter]

> Wait, I'm not even sure this is true.  I found two patch variants, a newer one and a superseded older one, and neither had been reviewed, just assigned a reviewer.  Did I miss the actual LGTM'd patch?

I'm referring to this: https://codereview.chromium.org/1312843006#ps1

If I'm wrong in assuming that the patch has been reviewed - do you have a reason for why it hasn't been?

OlegM

[Peter Kasting]

On Mon, Feb 22, 2016 at 6:54 PM, Dexter <sin...@gmail.com> wrote:

> Wait, I'm not even sure this is true.  I found two patch variants, a newer one and a superseded older one, and neither had been reviewed, just assigned a reviewer.  Did I miss the actual LGTM'd patch?

I'm referring to this: https://codereview.chromium.org/1312843006#ps1

Yeah, there's no review done on that patch.

If I'm wrong in assuming that the patch has been reviewed - do you have a reason for why it hasn't been?

Until we decide that we're willing to take the feature in principle, there's no reason to spend the time reviewing it.

I don't mean that to sound chicken-and-egg w.r.t. concerns about code footprint; we wouldn't reject a feature due to code footprint worries when we hadn't glanced at a patch to see what the actual footprint was.  I primarily refer to other concerns about APNG besides code/security impact.

That said, I know I glanced at this patch months back (along with a few other people) and was concerned that it didn't look terribly simple.  Which isn't surprising, given that supporting a new animated image format is not a trivial thing.

PK

[Dexter]

> until we decide that we're willing to take the feature in principle

And the decision process is hidden from outside view, so here we go again...

OlegM

[Max Stepin]

On Tuesday, February 23, 2016 at 5:19:28 AM UTC+3, Peter Kasting wrote:

The majority of GIFs on the web today really ought to be videos, not images.

The majority of them, sure. But just like every image shouldn't be a JPEG, not every animation should be a webm/mp4. So what to do with the considerable percentage of GIFs that should be animated images? Keep them as GIFs? There is a reason nobody uses static GIFs now, in 2016. And if they are not good for static...
 

The only compromise here would be to support both WebP and APNG and see who wins

Or support neither.  Which is a position I personally wouldn't mind taking.

But again:

https://www.google.com/logos/doodles/2016/valentines-day-2016-5699846440747008-5096695956242432-ror.gif
GIF: 260 212 bytes

APNG: 212 480 bytes

Where are all these WebPerf experts when you need them? I guess too busy twitting with #perfmatters and #pagespeed, while no one wants to deal with this elephant in the room...

Max.

[sin...@gmail.com]

So, what's the timeframe for the final decision according to your regulations? Product management is not Congress to play filibusters.

OlegM

[Mike Lawther]

There is no timeframe.

[sin...@gmail.com]

Good to know. At least now we can finally report to the media with certainty that you are blocking the decision with bureaucracy.

OlegM

[Max Stepin]

Some outside-of-browser news:

APNG is getting more popular (at least in Japan), as Line messenger started to supports animated stickers:
https://creator.line.me/en/guideline/animationsticker/

Stickers for Apple iMessages also support APNG:
https://developer.apple.com/reference/messages

Thanks to all that Japan traffic, downloads for my small APNG creation tool jumped from 1K/month to 5K/month:
https://sourceforge.net/projects/apngasm/files/stats/timeline?dates=2016-01-01+to+2016-06-30

That's a lot of people creating lots of APNG files.

[Dru Knox]

Hi all,

A quick update here: we've decided to moved forward with implementing APNG. We're looking for staffing now and should tentatively be able to start in Q4. Thanks for all of the information and motivation to get to this point! :)

-Dru

[xxv...@gmail.com]

Thanks, I was just looking at this and OP's post on twitter about it, and notified him on the update.
Wish I could be of more help =P

[Anne van Kesteren]

> We've been having discussions with some folks at Mozilla to make sure that
> if we go ahead with this, that Chrome and Firefox will be consistent in what
> we present to web developers. Quite recently Mozilla registered a new MIME
> type (http://www.iana.org/assignments/media-types/image/vnd.mozilla.apng),
> and we see how this is used as critically important for APNG. Web developers
> looking to adopt APNG will need to be able to fall back for browsers that
> still don't support it, and the last thing we want is for them to have to
> write yet more UA sniffing code.

As a heads up, we course-corrected and used image/apng instead. Code
landed recently in
https://bugzilla.mozilla.org/show_bug.cgi?id=1160200. Looking forward
to the Blink implementation later this year!


--
https://annevankesteren.nl/

[Mike Lawther]

Thanks for the heads up Anne!

[Peter Kasting]

Please pass on my thanks to the relevant decision makers on that one.  That makes me feel a lot better about shipping this in Chrome.

PK 

[Max Stepin]

So now we have 2 implementations? Well, OK. :)

10 months old:
https://codereview.chromium.org/1567053002/

1 month old:
https://codereview.chromium.org/2386453003/

Max.

[joostou...@google.com]

Hey Max,

Thanks for your enthusiasm and contributions to APNG support in Chromium. Before starting our work we did review your implementation, but we decided that the fastest path to getting an implementation that could be shipped in blink was to start from scratch. I used your code as a reference, so it was definitely not a waste of your time -- thanks! However, we should have included you in this discussion from the start so that you weren't surprised - sorry about that!

I'm optimistic that we're on a good path to ship APNG support in Chrome soon. If you can try out what we've done and file bugs for any issues you discover, that would be really helpful in getting a high-quality implementation available to web developers asap.

[Max Stepin]

Thanks, Joost. That's nice to hear!

Please consider including these APNG tests:
http://littlesvr.ca/apng/test.html
Nothing fancy, but they cover a lot of features, and they're already in WebKit as

LayoutTests/fast/images/animated-png.html

LayoutTests/fast/images/animated-png-expected.html

It would be nice to cover the same basics in Blink and WebKit, for consistency between engines. I think I'll ask Mozilla to include them too, as it looks like one of them would've helped to catch a recent APNG regression in Firefox.

Max.

[joostou...@google.com]

I agree with you that it would be great if there is if there is consistency in APNG decoding for the different engines out there. The best way to achieve this is to contribute to web-platform-tests [1], which is imported by Chromium [2]. Afaik WebKit and Firefox also use this suite. If you feel like it, you can submit the tests to web-platform-tests :) Otherwise we'll try to get it in there.

Joost

[1] https://github.com/w3c/web-platform-tests

[2] https://www.chromium.org/blink/importing-the-w3c-tests