Let's consider APNG support once again.

[Max Stepin]

Last time the APNG support idea was mentioned here on Chromium-dev, it was met with some skepticism, though not outright rejection:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/0eL52wJPQhw/discussion
But some things changed since then, so maybe it's time to reconsider?

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

2. I hacked APNG support into Chromium and it's 100% functional, works just fine. For now, I put the code here:
http://sourceforge.net/projects/apng/files/Chromium/
I realize that patching two separate src/third_party/ projects (libpng and WebKit) is a serious obstacle. But it's not impossible, right?

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

So what do you guys think?

[Paweł Hajdan, Jr.]

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

2. I hacked APNG support into Chromium and it's 100% functional, works just fine. For now, I put the code here:
http://sourceforge.net/projects/apng/files/Chromium/
I realize that patching two separate src/third_party/ projects (libpng and WebKit) is a serious obstacle. But it's not impossible, right?

I think WebKit is the easier part, since we have a lot of WebKit committers on the team.

Getting the patch into libpng (especially libjpeg-turbo that we use) would be the biggest step - having custom patches there doesn't really sound like the best idea. Alternatively, if you can implement the feature on top of it, but without modifying libpng library (so that people who want can continue to use the system one) that's also something to consider.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

So what do you guys think?

I'll let others comment more on this.

Paweł

[Max Stepin]

I posted WebKit portion here, maybe someone could review it? For some platforms, that would be enough:
https://bugs.webkit.org/show_bug.cgi?id=17022

About libpng... upstream position is well known. But the apng patch for libpng exists for 6 years now, it's well known also. And it's well maintained. Besides, right now src/third_party/libpng is not a vanilla 1.2.45 anyway. It's custom-security-patched by Chromium. And it's almost 2 years old.

Mozilla updated their libpng copy many times over the years without problems, despite having to keep apng support, and it's currently at the latest version: 1.5.14. It's not too hard to keep it maintained.

[Peter Kasting]

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

Does WebP support animation yet?  (I know it's been planned.)  I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

[Bernhard Bauer]

On Mon, Mar 18, 2013 at 8:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

The latter is correct, but I wouldn't say that we ignore stars on bugs. They are a decent indicator of the relative importance of features compared to each other (and in fact we do tell people to star bugs they wish to be fixed), it's just that users who file/star bugs are not a representative subset of all of our users.

Bernhard.

 

Does WebP support animation yet?  (I know it's been planned.)  I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Peter Kasting]

On Mon, Mar 18, 2013 at 1:04 PM, Bernhard Bauer <bau...@google.com> wrote:

On Mon, Mar 18, 2013 at 8:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

The latter is correct, but I wouldn't say that we ignore stars on bugs. They are a decent indicator of the relative importance of features compared to each other (and in fact we do tell people to star bugs they wish to be fixed), it's just that users who file/star bugs are not a representative subset of all of our users.

And bugs with large star counts are usually victims of internet popularity contests, where people star some thing because someone on Slashdot told them to or whatever, but in reality the feature may not actually impact that person at all.  In fact, if anything, bugs with large star counts are often more likely to be WontFix.

Bugs with, say, 20 or 30 stars may actually be more important than bugs with 2 stars, though.  So maybe "ignore completely" is overkill :)

PK 

[Max Stepin]

> I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.

Actually no, if you read the reviews here:
https://chrome.google.com/webstore/detail/apng/ehkepjiconegkhpodgoaeamnpckdbblp/reviews
it's clear that people are installing it NOT preemptively. They are actually using it. Some are even complaining about Chrome performance when there are too many apng files on the page. And most on them wish for native support in Chrome.

WebP was added to WebKit, so why not APNG? I think adding 360 lines of source code into PNGImageDecoder.cpp is not a big deal. It's not a totally new format, just a simple extension over existing PNG, so it's easy to implement.

[Mike Frysinger]

On Mon, Mar 18, 2013 at 4:22 PM, Max Stepin <new...@gmail.com> wrote:
> WebP was added to WebKit, so why not APNG? I think adding 360 lines of
> source code into PNGImageDecoder.cpp is not a big deal. It's not a totally
> new format, just a simple extension over existing PNG, so it's easy to
> implement.

the annoying thing about APNG is that the PNG people themselves
rejected it. you can't say the same thing about WebP.
-mike

[Max Stepin]

APNG is the third-party extension over PNG.

The job of libpng is to be a reference library, not to support every PNG extension invented by third-parties. But it's open-source under permissive license, so...

[Mike Frysinger]

i'm aware of what APNG is. the authors submitted it to the PNG group,
and they rejected it, hence support was also rejected for adding it to
libpng.

the same can not be said of WebP support -- it's not relying on a
series a non-standard extensions to the official spec.
-mike

[Max Stepin]

I only mentioned WebP because Peter asked about "actual prevalence of APNGs in the wild" and it seems to suggest that people should start using a new format, and use it a lot, before it could be included in WebKit. So I wonder how WebP managed to avoid such Catch 22.

Many big-name distros like: Arch, Gentoo, Mageia, FreeBSD already ship with system libpng that is apng-patched. For those platforms, it's only a matter of WebKit using that extended libpng. My patch does all that by adding 360 lines into PNGImageDecoder.cpp

[Mike Frysinger]

i'm aware Gentoo supports APNG ... i'm the one who added it ;).  but that was purely because i had a device that used APNGs, not because it's something i think should see wider deployment.  it also doesn't come enabled by default ... the end user has to explicitly enable themselves.

really, the standard needs to be formalized by the PNG group themselves ...

-mike

[Pascal Massimino]

Hi Peter, all,

On Mon, Mar 18, 2013 at 12:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

Does WebP support animation yet?  (I know it's been planned.)

yes, it's been in the HEAD codebase since quite some time now, along with the doc update [1].

The next official version (0.3.0) will freeze these into an official release (probably next week or so).

skal

[1] http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob;f=doc/webp-container-spec.txt;h=929d5fa465cd82e009c6f74a61de0933815e9a7b;hb=HEAD

 

 I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

--

[Max Stepin]

When I tried gentoo 20121221.iso it just worked, I didn't have to enable anything. APNG worked out of the box. Just like with other distros.

[Mike Frysinger]

unfortunately, this was done specifically for desktop profiles based on the assumption that the majority of people will be installing firefox which itself requires apng support.  if firefox ever stops requiring that, it'll be dropped again.

-mike

--

[Max Stepin]

Firefox is never going to drop APNG support, there are too many APNG files in the wild for that.

[Daniel Bratell]

Den 2013-03-18 20:47:00 skrev Peter Kasting <pkas...@chromium.org>:

> On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:
>
>> 1. Presto supported APNG, so Opera devs would probably like not to lose
>> that feature.
>>
>
> Presto had many differences from WebKit/Chromium. I imagine the Opera
> folks will decide on a case-by-case basis what they wish to do about
> those.
> For the moment, I wouldn't pre-emptively add APNG support with the
> explicit goal of minimizing differences with Presto.

While it sucks to lose features through the switch of web engine, I don't
think APNG is high on the list of things to restore support for. I'm sure
nobody would be sad to see it return, but I also don't think it will break
the web if it's missing. Bigger fish and so on.

/Daniel

[Max Stepin]

While it sucks to lose features through the switch of web engine, I don't  
think APNG is high on the list of things to restore support for.

 
That's perfectly understandable if you don't want to spend any time on this. But that's why I'm not asking people to write the code for apng support. I already wrote it. I'm only asking people to accept my patch.

I'm sure nobody would be sad to see it return 

Would you support my patch, then? I really don't see any negatives in accepting it, really. Only positives.

I'm a bit surprised at the reaction here. I have yet to hear any concrete, specific objections. What's the worst that could happen? 256-color, 1-bit alpha GIF will finally disappear as the '80s format? For 2013, it's long overdue.

[Mike Frysinger]

i think you're forgetting the bigger picture. every bit of active
code is increased maintenance and possible attack surface. so what's
the worse that could happen you ask ? the apng code has bugs which
allow people to post malicious/corrupt images that allow exploiting of
render processes which, when combined with other bugs, allow remote
execution on the system.

i'm not saying apng has these problems, just pointing out your
assumptions are fundamentally flawed here. "nothing is free".
-mike

[Max Stepin]

apng support adds like 5% to libpng size, plus 360 lines of code for PNGImageDecoder.cpp

Any new code is a possible attack surface, but this one is really really small.

And it's been exposed to the web by Firefox since 2008.

[Peter Kasting]

In fairness, though, image decoders are classically a key vector for exploits.  GIF support has been around far longer than APNG, and WebKit basically forked Firefox' GIF decoder, yet in the last year alone we've fixed multiple memory corruption issues as well as some other bugs with decoding.  So there is merit to the "we don't want the attack surface" argument just as there is merit to the "we don't want the maintenance surface" argument.  The issue is to what degree you perceive the pluses and minuses.  I suspect on this one, the perception is of a very small plus and some relatively small minuses.  The perfect recipe for apathy, or a bikeshed debate, depending on your point of view.

PK

[Max Stepin]

On Tuesday, March 19, 2013 10:41:36 AM UTC+4, Peter Kasting wrote:

In fairness, though, image decoders are classically a key vector for exploits.  

And no one would deny it. But most of the decoding work for png/apng is done by libpng. And while we saw some security updates for libpng over the years, I don't remember any of them caused by extra 5% apng functionality. Firefox exposed that functionality to the web since 2008 and Firefox is not an insignificant target.
 

So there is merit to the "we don't want the attack surface" argument just as there is merit to the "we don't want the maintenance surface" argument.

I'm not dismissing those arguments, but objectively, those surfaces are really small. Especially considering you want other browsers to adopt increasingly complex WebP. And by the way, I don't see anyone actively maintaining src/third_party/libpng anyway, it's stuck at very old 1.2.45 version since July 2011, while Mozilla regularly updates their libpng, and currently at the latest 1.5.14 version. Maybe you should just copy it from them, that would solve the maintenance issue and apng issue at the same time.
 

 The issue is to what degree you perceive the pluses and minuses.  I suspect on this one, the perception is of a very small plus and some relatively small minuses.

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus. "256 colors should enough for everybody" might have worked in 1989, but its 2013 now.

Nice comparison:
http://littlesvr.ca/apng/gif_vs_apng.html

 

[Stuart Morgan]

2013/3/19 Max Stepin <new...@gmail.com>

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus.

Do you believe that everyone would simply stop writing sites compatible with IE, Safari, and everything on iOS if Chromium supported APNG? If not, then claiming the plus here as "retiring GIF" is disingenuous.

I understand there's a chicken-and-egg issue here to some extent, but given that there's both an extension to add APNG support to Chromium, and also apparently a server-side polyfill that will translate APNG to canvas, it seems very unlikely that Chromium support is the deciding factor in widespread adoption. Which brings us back to Peter's point that the plus here seems quite small.

This probably isn't the right place for this discussion yet though; since the libpng part of your change isn't useful without the WebCore changes, starting on a WebKit list with trying to get that change accepted seems like the first step.

-Stuart

[Max Stepin]

On Tuesday, March 19, 2013 1:25:56 PM UTC+4, Stuart Morgan wrote:

Do you believe that everyone would simply stop writing sites compatible with IE, Safari, and everything on iOS if Chromium supported APNG? If not, then claiming the plus here as "retiring GIF" is disingenuous.

Well, it would be a significant push in the right direction.
 

I understand there's a chicken-and-egg issue here to some extent, but given that there's both an extension to add APNG support to Chromium, and also apparently a server-side polyfill that will translate APNG to canvas, it seems very unlikely that Chromium support is the deciding factor in widespread adoption.

Chromium support is absolutely the deciding factor here. On many serious websites (and even in some whole countries) Chrome+Firefox cover up to 80% of the users. That would be a significant jump from 25% share of Firefox, and people might actually start posting APNGs there. Other browsers would still see the first frame, it's a nice fallback mechanism.

 

This probably isn't the right place for this discussion yet though; since the libpng part of your change isn't useful without the WebCore changes, starting on a WebKit list with trying to get that change accepted seems like the first step.

I already posted the WebKit patch there and asked for review:
https://bugs.webkit.org/show_bug.cgi?id=17022
But nobody replied to me there, so I'm trying to have a discussion here instead.
I believe there must be some WebKit committers here too.

[Darin Fisher]

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

I think the answer probably involves http://sourceforge.net/mailarchive/message.php?msg_id=131482.  I am a bit nervous about supporting PNG extensions that the "PNG experts" have rejected.  I don't know the basis for their rejections, etc.

-Darin

[Max Stepin]

On Tuesday, March 19, 2013 7:22:41 PM UTC+4, Darin Fisher wrote:

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

Because official libpng is suppose to be the reference implementation of PNG. While PNG specs clearly allows extensions by using third-party chunks, the reference implementation doesn't have to support such third-party functionality. But libpng is open source, with permissive license, so its functionality can be extended by others, there's nothing wrong with that. 

The patch is well maintained (by me) for years now. And as already mentioned, apng-patched system libpng is a part of some well-known distros, for years. It doesn't cause any problems for them.

[Adam Barth]

Max,

Thus far it looks like you're the only advocate for APNG on this thread.  Perhaps we should give other members of the Chromium community a chance to voice their views on this subject.

Adam

[Dominic Mazzoni]

I don't buy the argument that we shouldn't support it because libpng won't accept it, or because the PNG standards group won't accept it. Chromium implements lots of de facto web standards when they're adopted by other browsers and used by web developers. In fact, we probably implement several de facto web standards that are far less prevalent than APNG.

If the consensus is that we don't want to take APNG now because the added technical and security cost don't seem worth the user benefit, that's fine - I don't have a strong opinion there - but I think we should keep an eye on adoption and reconsider if it seems to be growing in popularity among web developers.

Max, thanks for your work in creating the patches and for having a great civil discussion and for sticking to facts and technical arguments.

- Dominic

[Peter Kasting]

On Tue, Mar 19, 2013 at 1:01 AM, Max Stepin <new...@gmail.com> wrote:

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus. "256 colors should enough for everybody" might have worked in 1989, but its 2013 now.

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.  It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

On Tue, Mar 19, 2013 at 8:22 AM, Darin Fisher <da...@chromium.org> wrote:

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

I think the answer probably involves http://sourceforge.net/mailarchive/message.php?msg_id=131482.  I am a bit nervous about supporting PNG extensions that the "PNG experts" have rejected.  I don't know the basis for their rejections, etc.

From a combination of memory and Wikipedia: the PNG format was intentionally designed as a single-image format, and the spec notes ( http://www.libpng.org/pub/png/spec/1.1/PNG-Misc.html#Multiple-image-extension , http://www.libpng.org/pub/png/spec/1.1/PNG-Rationale.html#R.Why-not-these-features ) that multi-image cases are explicitly not to be supported in PNG.  The PNG standard committee worried about the consequences of reversing this decision, e.g. that because of Mozilla's decision to make APNGs backwards-compatible, non-supporting editors would fail to notify users that the image had multiple frames, or would modify the image unexpectedly (removing the animation) on loading it and saving it back out.  Basically, the committee wanted to see animation implemented using something that was distinct from existing PNGs, whereas much of the design goal of APNG was precisely to be "a PNG, plus some extra stuff supporting clients may additionally understand".

PK

[Darin Fisher]

Thanks for digging up that history, Peter.  I agree with you that animated WebP seems  much more compelling than APNG.  I'd much rather put effort into making animated WebP ubiquitous.

Dominic, it is true that compatibility across implementations (different browsers) is what matters most.  Features don't need to be codified as standards to be adopted by browsers, etc.  That said, I figured the PNG group probably had some reasons for rejecting APNG, and based on what Peter wrote, it seems like those reasons are rational.

-Darin

[Max Stepin]

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too? At least APNG is very simple with the nice fallback to static PNG for all other browsers. If it's "reasonable to consider alternatives to APNG " why can't we at first give a serious consideration to APNG itself? Wouldn't that be fair? We have not even touched any technical stuff yet.

 It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

I don't you're being fair, since it's completely false. Even GIFs can do deltas, and APNG can do everything GIF does. You absolutely can encode deltas in APNGs, just look at the "GIF vs. APNG" comparison here, it includes the filesizes:

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

[Max Stepin]

On Wednesday, March 20, 2013 8:30:44 AM UTC+4, Darin Fisher wrote:

Thanks for digging up that history, Peter.

Here's more history to consider:

http://www.boutell.com/innards/apng.html

[Darin Fisher]

On Tue, Mar 19, 2013 at 9:32 PM, Max Stepin <new...@gmail.com> wrote:

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too? At least APNG is very simple with the nice fallback to static PNG for all other browsers. If it's "reasonable to consider alternatives to APNG " why can't we at first give a serious consideration to APNG itself? Wouldn't that be fair? We have not even touched any technical stuff yet.

Yes, WebP adds attack surface.  However, WebP offers tremendous benefits (in terms of bandwidth savings), so it seems worth the cost to us.

-Darin

[Darin Fisher]

Thanks for the link.

-Darin

[Peter Kasting]

On Tue, Mar 19, 2013 at 9:32 PM, Max Stepin <new...@gmail.com> wrote:

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too?

Absolutely, but we've already made a decision to include WebP, and that decision isn't what's at issue here.  We're talking about adding APNG or not in addition to WebP.

 

 It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

I don't you're being fair, since it's completely false. Even GIFs can do deltas, and APNG can do everything GIF does. You absolutely can encode deltas in APNGs, just look at the "GIF vs. APNG" comparison here, it includes the filesizes:

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

I don't really see how this page proves either of our statements.  "X can be bigger than Y" is not falsified by finding three cases where X is not bigger than Y.

I would be very surprised if APNG can really "do everything that GIF does" since GIF does many things, a lot of them stupid.  (I am pretty familiar with the GIF format, sadly.)

Finally, I was pretty careful not to put an editorial slant of my own onto the PNG committee's decision to not standardize APNG.  For the record, at the time it happened I disagreed with the decision.

PK

[Max Stepin]

On Thursday, March 21, 2013 1:12:21 AM UTC+4, Peter Kasting wrote:

Absolutely, but we've already made a decision to include WebP, and that decision isn't what's at issue here.

Of course, but I'm talking about other browsers. You don't think by promoting WebP for the whole Web you might encounter the exact same arguments from others? What would be your counter-arguments then? I want to borrow them for APNG support... ;)

It seems that situations are kinda similar: WebP was invented mostly to be a JPEG alternative, and APNG was invented to be a GIF alternative. I have nothing against WebP as it's clearly better than JPEG, so it's a bit strange to see other people oppose APNG so strongly, even though it's similarly better than GIF. And it's very simple. And the code is ready.
 

I don't really see how this page proves either of our statements.

It just an illustration. I know for a fact those example have deltas, since I created them with deltas.
Why are you claiming that APNGs can't do deltas, even though the specs says they can?
Let's have arguments based on facts.

 

I would be very surprised if APNG can really "do everything that GIF does" since GIF does many things, a lot of them stupid.  (I am pretty familiar with the GIF format, sadly.)

Well, it can do all the important things GIF does: dispose and blend ops, deltas, delays etc. And it avoids a lot of GIF mistakes, for example APNG has the number-of-frames field in the acTL header. I'm sure you know it's a major pain for GIF: have to decode the whole file just to know the number of frames. With APNG you know if it's animated or static before you read the first IDAT chunk. And GIF doesn't even have 32-bit integer fields, only 8-bit and 16-bit, that's how ancient it is.

[Alpha Lam]

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag? Displaying animated images uses a different pipeline than <video> that is much slower.

Alpha

2013/3/18 Pascal Massimino <pascal.m...@gmail.com>

[Matt Giuca]

On 21 March 2013 10:16, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag? Displaying animated images uses a different pipeline than <video> that is much slower.

But that's just a Chrome-specific (or WebKit-specific) pipeline, right? Someone building general websites isn't going to care about that. I haven't used WebP, but presumably it gives you the same features as GIF (namely, it can go in an <img> tag so it's possible to post it on most forums, it animates without user interaction so it's good for memes like just having dozens of GIFs as you scroll down the page, and it's got no controls or audio so it feels much more lightweight).

[Pascal Massimino]

Alpha,

On Wed, Mar 20, 2013 at 4:16 PM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag? Displaying animated images uses a different pipeline than <video> that is much slower.

well, it's true that any animation turns into a video when growing long enough :)

The rationale has been (as far as WebP decoder organisation is concerned): instantiating a full video codec for just few tiny animated frames is overkill.

And not just because the codec runs into a sandbox (heavy hit #1). But also because, while writing the decoder, you can make a lot of optimizations

if you know you're only decoding a single frame of a, agreed, video format. For instance, libwebp emits the pixels on a per-row basis once they're ready

and only use memory that is proportional to the _width_ of the image, not the _size_ (width x height) of the image. There's other shortcuts (like, not having

to keep reference frames traditionally used for frame prediction in video codec), but not as important...

Now, imagine when you're landing on a forum page with zillions of animated avatars, the difference it makes in resources consumption...

[Victor Khimenko]

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

[PhistucK]

See my comment inline.

☆PhistucK

On Thu, Mar 21, 2013 at 5:59 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Hm, how would WebP work here if the extensions are limited to .png, .jpg and .gif?

APNG is actually the best (or only) choice here (not advocating or anything), if we are talking about this use case, due to full backward compatibility.

[Victor Khimenko]

On Thu, Mar 21, 2013 at 8:35 PM, PhistucK <phis...@gmail.com> wrote:

See my comment inline.

On Thu, Mar 21, 2013 at 5:59 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Hm, how would WebP work here if the extensions are limited to .png, .jpg and .gif?

Save your webP animation with a .png extension. Problem solved.

 

APNG is actually the best (or only) choice here (not advocating or anything), if we are talking about this use case, due to full backward compatibility.

Well, yeah, but it does not look like people will start using it for animations till large enough proportion of web browsers will adopt it anyway - and on server side there are no problems as I've pointed out above: Most browsers are happy to accept PNG file with an .jpg extension or .gif under .png name. Chrome will accept webP if it's named something.png so and it's obvious other browsers can do the same, too.

Which means that while from formal POV APNG has the best compatibility in practice webP works just as well - just in different browser.

P.S. And yes, it works even if web server serves said webP with "image/png" MIME type (as it should). And yes, I know it's blatant violation of standards. And I can even understand why PNG experts say about APNG that it "was a repeat of some of the same mistakes made in the GIF format 10 years earlier" (http://en.wikipedia.org/wiki/APNG). But I'm practical guy. What I see are two solutions: one (GIF89a) have taken the world by storm and was quickly adopted more-or-less by everyone while another one (MNG) was spurned by everyone and after more then a decade is not used by anyone while everyone still uses GIF89a (with it's limitations of 256 colors and all) I can only sigh... it's just too sad for the words.

P.P.S. I don't particularly care if Chrome will adopt APNG or if Firefox will adopt webP (both solutions will give us a pictures animation format which can be used by majority of browsers), but the situation when people are forced to continue to use GIF89a in 2013 looks worse to me then both these alternatives.

[PhistucK]

See my comments inline.

☆PhistucK

On Thu, Mar 21, 2013 at 7:57 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Mar 21, 2013 at 8:35 PM, PhistucK <phis...@gmail.com> wrote:

See my comment inline.

On Thu, Mar 21, 2013 at 5:59 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Hm, how would WebP work here if the extensions are limited to .png, .jpg and .gif?

Save your webP animation with a .png extension. Problem solved.

Not quite - some servers actually check the uploaded file to make sure it really is a PNG image and reject it otherwise.

 

 

APNG is actually the best (or only) choice here (not advocating or anything), if we are talking about this use case, due to full backward compatibility.

Well, yeah, but it does not look like people will start using it for animations till large enough proportion of web browsers will adopt it anyway - and on server side there are no problems as I've pointed out above: Most browsers are happy to accept PNG file with an .jpg extension or .gif under .png name. Chrome will accept webP if it's named something.png so and it's obvious other browsers can do the same, too.

Which means that while from formal POV APNG has the best compatibility in practice webP works just as well - just in different browser. 

P.S. And yes, it works even if web server serves said webP with "image/png" MIME type (as it should). And yes, I know it's blatant violation of standards.

Web pollution. :(

 

And I can even understand why PNG experts say about APNG that it "was a repeat of some of the same mistakes made in the GIF format 10 years earlier" (http://en.wikipedia.org/wiki/APNG). But I'm practical guy. What I see are two solutions: one (GIF89a) have taken the world by storm and was quickly adopted more-or-less by everyone while another one (MNG) was spurned by everyone and after more then a decade is not used by anyone while everyone still uses GIF89a (with it's limitations of 256 colors and all) I can only sigh... it's just too sad for the words.

P.P.S. I don't particularly care if Chrome will adopt APNG or if Firefox will adopt webP (both solutions will give us a pictures animation format which can be used by majority of browsers), but the situation when people are forced to continue to use GIF89a in 2013 looks worse to me then both these alternatives.

I agree, of course.

[Alpha (Hin-Chung) Lam]

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Are you suggesting a new animated image format is backward compatible? I don't think many of the new HTML5 features we're developing works in those 10 years old PHPBB sites. I'd surprised to see this as an argument for developing something new.

Animated images do not render well in modern browsers and they hog Chrome performance. <video> tag is newly designed and implemented to support high performance rendering. Animated images is technically backwards.

Here's a list of performance bugs with animated GIFs.

This animated GIF takes about the same CPU as playing this H264 video in 720p.

Alpha

[Victor Khimenko]

On Thu, Mar 21, 2013 at 10:52 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Are you suggesting a new animated image format is backward compatible?

Yes. Note that we already have perfectly well-supported non-backward-compatible animated image format: SVG. Unfortunately it's can not be used in many places where APNG (or webP) can be used.

 

I don't think many of the new HTML5 features we're developing works in those 10 years old PHPBB sites.

Depends on what plugins to PHPBB are installed and how they use these HTML5 features. Actually it's just "living standard called html" now because we don't want to force to upgrade the whole infrastructure all-at-once.

 

I'd surprised to see this as an argument for developing something new.

Why not? Backward-compatibility is very important argument and it often trumps other considerations. Or do you know any OTHER reason not to follow up with our own promise: http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html ?

Animated images do not render well in modern browsers and they hog Chrome performance.

Then this must be fixed (if it can be fixed). People are using them and they will use them no matter what we do. It's the question of "will they use animated images or <video> tag?" but rather "will they continue to use GIF89a or can we offer something better?".

 

<video> tag is newly designed and implemented to support high performance rendering. Animated images is technically backwards.

Here's a list of performance bugs with animated GIFs.

This animated GIF takes about the same CPU as playing this H264 video in 720p.

Good example. Please give me an URL with "H264 video" analogue of the first GIF on photobucket.com and we'll have a deal. Or, better yet, please reply to my mail with another one where <video> tag is used in place of the following picture:

Gmail is nice modern HTML5 application so why it's so hard if nice modern <video> tag is ready to replace GIF89a and APNG?

There a large number of places where you can put animated GIF and it's easy and simple to use APNG in them (after some thinking I admit that webP is less useful there: for example photo hosting sites will offer thumbnail of the first frame in APNG as a small icon for you but will most likely create garbage for webP): web forums, photo hosting sites, etc.

[Elliott Sprehn]

On Thu, Mar 21, 2013 at 2:52 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Are you suggesting a new animated image format is backward compatible? I don't think many of the new HTML5 features we're developing works in those 10 years old PHPBB sites. I'd surprised to see this as an argument for developing something new.

Animated images do not render well in modern browsers and they hog Chrome performance. <video> tag is newly designed and implemented to support high performance rendering. Animated images is technically backwards.

Here's a list of performance bugs with animated GIFs.

This animated GIF takes about the same CPU as playing this H264 video in 720p.

I don't think this is a reasonable argument for not supporting APNG, or for hating on gif. We've just not invested much engineering effort on making it fast.

We certainly could GPU accelerate gifs, we could even transparently translate them into WebP. pdr@ had even mentioned GPU acceleration for gifs recently.

- E

[Alpha (Hin-Chung) Lam]

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 10:52 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Are you suggesting a new animated image format is backward compatible?

Yes. Note that we already have perfectly well-supported non-backward-compatible animated image format: SVG. Unfortunately it's can not be used in many places where APNG (or webP) can be used.

 

I don't think many of the new HTML5 features we're developing works in those 10 years old PHPBB sites.

Depends on what plugins to PHPBB are installed and how they use these HTML5 features. Actually it's just "living standard called html" now because we don't want to force to upgrade the whole infrastructure all-at-once.

 

I'd surprised to see this as an argument for developing something new.

Why not? Backward-compatibility is very important argument and it often trumps other considerations. Or do you know any OTHER reason not to follow up with our own promise: http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html ?

I really don't see the point of mentioning this post. Ever since there's HTML5 <video> in Chrome/Chromium, there's Theora support, WebM was added later after it was announced.

 

Animated images do not render well in modern browsers and they hog Chrome performance.

Then this must be fixed (if it can be fixed). People are using them and they will use them no matter what we do. It's the question of "will they use animated images or <video> tag?" but rather "will they continue to use GIF89a or can we offer something better?".

I think we should fix these performance issues first before considering supporting any new animated formats. It'll be great if there's volunteers to fix these issues.

In terms of features does APNG support hardware decoding? Does it support seeking? Does it support audio? I don't think animated images will ever be better than <video>, video tag is clearly a better offer in terms of technical capabilities.

 

 

 

<video> tag is newly designed and implemented to support high performance rendering. Animated images is technically backwards.

Here's a list of performance bugs with animated GIFs.

This animated GIF takes about the same CPU as playing this H264 video in 720p.

Good example. Please give me an URL with "H264 video" analogue of the first GIF on photobucket.com and we'll have a deal. Or, better yet, please reply to my mail with another one where <video> tag is used in place of the following picture:

Gmail is nice modern HTML5 application so why it's so hard if nice modern <video> tag is ready to replace GIF89a and APNG?

Why shouldn't the Web move to modern HTML5 applications? There's youtube, vimeo, etc. You keep getting back to specific web sites but didn't mention the technical advantages of <video> over animated images.

[Scott Hess]

On Thu, Mar 21, 2013 at 1:55 PM, Elliott Sprehn <esp...@chromium.org> wrote:

We certainly could GPU accelerate gifs, we could even transparently translate them into WebP. pdr@ had even mentioned GPU acceleration for gifs recently.

We could even allow video resources in img tags, if we wanted to allow people to serve new static resources without modifying ancient infrastructure.

http://www.computerhope.com/issues/ch000591.htm#3 seems to imply that that must have worked for some browser at some time.

-scott

 

[Max Stepin]

On Friday, March 22, 2013 1:02:17 AM UTC+4, Alpha Lam wrote:

In terms of features does APNG support hardware decoding? Does it support seeking? Does it support audio? I don't think animated images will ever be better than <video>, video tag is clearly a better offer in terms of technical capabilities.

 

On some forums I visit people have animated GIFs avatars.
They can be annoying sometimes, but I'm very thankful they can't have audio. :)

Having a simple format is not always a bad thing.

[Alpha (Hin-Chung) Lam]

2013/3/21 Alpha (Hin-Chung) Lam <hc...@google.com>

Here's a CL that adds support for alpha channel in <video> tag. I would like to know what features that animated image support but <video> doesn't.

[Victor Khimenko]

On Fri, Mar 22, 2013 at 1:02 AM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 10:52 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

2013/3/21 Victor Khimenko <kh...@chromium.org>

On Thu, Mar 21, 2013 at 3:16 AM, Alpha Lam <hc...@chromium.org> wrote:

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag?

Because it's PHPBB-based site with engine from 10 years ago which allows upload of only .GIF/.PNG/.JPG? Where do you think all these animated GIFs are commonly used today?

 

Displaying animated images uses a different pipeline than <video> that is much slower.

May be, but any solution which pretends to be backward compatible should work with the limitations outlined above (img tag, only files with extensions .gif/.png/.jpg are allowed). Both APNG and WebP actually work fine in such situation while tag <video> obviously is a non-starter.

Are you suggesting a new animated image format is backward compatible?

Yes. Note that we already have perfectly well-supported non-backward-compatible animated image format: SVG. Unfortunately it's can not be used in many places where APNG (or webP) can be used.

 

I don't think many of the new HTML5 features we're developing works in those 10 years old PHPBB sites.

Depends on what plugins to PHPBB are installed and how they use these HTML5 features. Actually it's just "living standard called html" now because we don't want to force to upgrade the whole infrastructure all-at-once.

 

I'd surprised to see this as an argument for developing something new.

Why not? Backward-compatibility is very important argument and it often trumps other considerations. Or do you know any OTHER reason not to follow up with our own promise: http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html ?

I really don't see the point of mentioning this post. Ever since there's HTML5 <video> in Chrome/Chromium, there's Theora support, WebM was added later after it was announced.

Right. And when that was done there was a promise to kill H.264 ("support for the codec will be removed and our resources directed towards completely open codec technologies" is pretty unambiguous promise, right?) - which never happened. If WebM is indeed superior format and backward compatibility is of little importance then why exactly that never happened?

Animated images do not render well in modern browsers and they hog Chrome performance.

Then this must be fixed (if it can be fixed). People are using them and they will use them no matter what we do. It's the question of "will they use animated images or <video> tag?" but rather "will they continue to use GIF89a or can we offer something better?".

I think we should fix these performance issues first before considering supporting any new animated formats. It'll be great if there's volunteers to fix these issues.

In terms of features does APNG support hardware decoding? Does it support seeking? Does it support audio? I don't think animated images will ever be better than <video>, video tag is clearly a better offer in terms of technical capabilities.

May be so, but animated images are used in many places where you can not use <video> tag - not any time soon, at least.

  

<video> tag is newly designed and implemented to support high performance rendering. Animated images is technically backwards.

Here's a list of performance bugs with animated GIFs.

This animated GIF takes about the same CPU as playing this H264 video in 720p.

Good example. Please give me an URL with "H264 video" analogue of the first GIF on photobucket.com and we'll have a deal. Or, better yet, please reply to my mail with another one where <video> tag is used in place of the following picture:

Gmail is nice modern HTML5 application so why it's so hard if nice modern <video> tag is ready to replace GIF89a and APNG?

Why shouldn't the Web move to modern HTML5 applications?

You mean GMail is not modern enough?

 

There's youtube, vimeo, etc.

These are VIDEO-sites. They are good for what they are doing, but they can not used as a replacement for a simple animated image.

 

You keep getting back to specific web sites but didn't mention the technical advantages of <video> over animated images.

There are many technical advantages, but there are serious problem, too: it's not a drop-in replacement. You can not use tag <video> on many sites (including advanced HTML5-based sites like GMail), you can not use them as a background for an element, etc.

Basically people are begging for a better car and you explain again and again that Concorde is faster. Sure it's faster but you can not use it where you need car thus comparison is quite pointless.

[mofo syne]

Let me throw my voice in, that I agree with what khim said.

Frankly this fragmentation of web animation standards is getting very annoying. And just because webm is good at being a video container, does not mean it is good for the purpose that people use GIF for.

We use gif, for animated backgrounds, short looping clips. A common thing is that we don't want to have to bother about "autoplay tags" etc... we just want to insert it in as an image and have it work. Which to my experience, APNG does so handsomely. I am eager to see if animated webp could be the revolution that APNG could not be due to petty internet politics (seriously what the hell is the delay, with APNG for chrome?).

Here's to hoping that webp will be supported in firefox (chrome already has it). Or at the very least APNG is supported by both. I don't care which. Just make it happen, we all waited long enough.

[Evgeny Vrublevsky]

Safari 8 has APNG support!

[mofo syne]

Hurray! *Three Cheers*

Now the chrome is the only one left needing APNG support! :D :/

[PhistucK]

Chrome and... Internet Explorer.

☆PhistucK

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

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

[mofo syne]

Nobody cares about IE

[VEG]

I hope that many iPhone users will start to use pictures in APNG, and other vendors (Google and Microsoft) will be forced to add APNG support to their browsers.

[PhistucK]

Yes, that is a very nice perspective. Very realistic. :)

☆PhistucK

[mofo syne]

Hmmmm... say... a imgur like website, where it accepts any sorts of
images, but retrieves only as APNG (but maybe still have gif
fallback)? Kind of like gfycat.com but for APNG . Make it very easy
for mobile users to use, and promote it's benefit for mobile users
(e.g. gfycat webm videos in mobile phones does not autoplay, and is a
bit more annoying to use).

If you do manage to set such service up, let me know. I certainly have
a few subreddits that can do with a dedicated APNG service.

[Max Stepin]

Since this discussion is up again, let me take this opportunity and post my latest APNG code for Chromium:
https://sourceforge.net/projects/apng/files/Chromium/

I also posted the WebKit version here:
https://bugs.webkit.org/show_bug.cgi?id=17022

The important difference: this latest code uses standard libpng.

Turns out it's possible. I bit tricky, but not impossible. The patch is still quite small.

[VEG]

Are Chromium developers reading this group? It's time to implement APNG!
I think immediately after this Mozilla will implement WebP support in Gecko. I think they do not support WebP because of resentment caused by the fact that Google has ignored APNG.

[Ryan Houdek]

So even Safari supports this. The only two big entities that don't support this is Chrome and Internet Explorer.

Just like Google to stifle technologies they don't like. They did it with OpenCL on Nexus devices in 2013. They did it with desktop OpenGL with the new Nexus 9, and they've been doing it with this feature for years longer.

Suppose Google's don't be evil motto doesn't cover not being shit.

On Monday, March 18, 2013 7:20:32 AM UTC-5, Max Stepin wrote:

Last time the APNG support idea was mentioned here on Chromium-dev, it was met with some skepticism, though not outright rejection:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/0eL52wJPQhw/discussion
But some things changed since then, so maybe it's time to reconsider?

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

2. I hacked APNG support into Chromium and it's 100% functional, works just fine. For now, I put the code here:
http://sourceforge.net/projects/apng/files/Chromium/
I realize that patching two separate src/third_party/ projects (libpng and WebKit) is a serious obstacle. But it's not impossible, right?

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

So what do you guys think?

[Stephen Chenney]

[From the right email]

At this stage the appropriate action is for you (or someone else with an interest in getting apng landed) to post an "Intent to Implement" email to blink-dev. The process is described at http://www.chromium.org/blink#launch-process.

I have no idea what the reception will be, but at least you'll get some attention and feedback.

Cheers,
Stephen.

[Max Stepin]

Thanks for the pointers.
I'm currently waiting for crbug.com/422794 to be fixed, and then I'll try that.

Max.

[PhistucK]

Note that I am not sure this is a polyfill per se, since you have to create three different versions for every image.

☆PhistucK

On Fri, Apr 3, 2015 at 2:03 PM, Alexey Solovey <act...@gmail.com> wrote:

My answer for WebP and APNG fans! 

https://github.com/acterhd/APNG

четверг, 13 ноября 2014 г., 3:13:03 UTC+8 пользователь Max Stepin написал:

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

[dv]

Desktop OpenGL on embedded devices is a very bad idea. You are supposed to use OpenGL ES there.
Same with full-blown OpenCL. There is OpenCL EP (embedded profile) for such devices.

--

[PhistucK]

​Still, a polyfill is usually something that works without any further action ("just put this script and it works").​

☆PhistucK

On Fri, Apr 3, 2015 at 4:11 PM, Alexey Solovey <act...@gmail.com> wrote:

I shared apng2gif and apng2webp conversion tools. 

пятница, 3 апреля 2015 г., 19:16:46 UTC+8 пользователь PhistucK написал:

[Давид Мзареулян]

Alexey, April 1st was two days ago:) Anyway, this group is for Chromium development, not for JS libs.

пятница, 3 апреля 2015 г., 14:03:20 UTC+3 пользователь Alexey Solovey написал:

My answer for WebP and APNG fans! 

https://github.com/acterhd/APNG

четверг, 13 ноября 2014 г., 3:13:03 UTC+8 пользователь Max Stepin написал:

Thanks for the pointers.

[PhistucK]

But you still have to create an APNG, a GIF and a WebP versions of every image...

☆PhistucK

On Fri, Apr 3, 2015 at 4:44 PM, Alexey Solovey <act...@gmail.com> wrote:

I removed extensions. Just paste detect.js, and will automaticly pickup image source. 

пятница, 3 апреля 2015 г., 21:22:13 UTC+8 пользователь PhistucK написал:

[Ben Bout]

How's this project coming along?

[Max Stepin]

I plan to rewrite the code for Chromium somewhat. Stay tuned.

My code for WebKit landed recently, with layout tests and everything:

https://bugs.webkit.org/show_bug.cgi?id=17022
http://webkitgtk.org/2015/03/23/webkitgtk2.8.0-released.html

[Alexey Solovey]

You can test APNG for chromium. 

https://onedrive.live.com/redir?resid=54d7da9cdef82b01!27581&authkey=!ABTsVDGMPEvdcBQ&ithint=folder%2ctxt

понедельник, 18 марта 2013 г., 20:20:32 UTC+8 пользователь Max Stepin написал:

[Jared Jones]

So is there any estimation as to when APNG will be put into Chrome by the official devs?

[Peter Kasting]

On Thu, May 28, 2015 at 5:56 PM, Jared Jones <jjo...@uvora.com> wrote:

So is there any estimation as to when APNG will be put into Chrome by the official devs?

There are no current plans to add APNG support.

PK 

[Joe Nosay]

I could use the argument that apng can deal with a transparent background while gif must have - at the least - an alpha background. Just think about it and see if it could be an added option in the chrome://flags page.

--

[Jared Jones]

Yea I don't get this.... It's almost like the Microsoft IE devs and the Chromium devs are in competition with one another about who can make the most outdated browser.

[Matt Giuca]

On Sun, 31 May 2015 at 06:28 Joe Nosay <superb...@gmail.com> wrote:

I could use the argument that apng can deal with a transparent background while gif must have - at the least - an alpha background. Just think about it and see if it could be an added option in the chrome://flags page.

We don't add options to the chrome://flags page. That page is for experiments that will eventually be turned on by default, or removed completely (it is not intended for perpetually available optional features).

[appletreepear]

Thanks for your work OP.

It's great to hear Firefox is adding WebP support http://www.ghacks.net/2016/08/24/mozilla-webp-support-firefox/
Still wish APNG was supported first. 2D game animations on the internet have been lacking for so long, both for previews such as on Kickstarter and for ease of sharing and use in game dev communities.

[PhistucK]

On Mon, Jan 2, 2017 at 4:20 AM, appletreepear <warfs...@gmail.com> wrote:

both for previews such as on Kickstarter and for ease of sharing

​Site issues - they could have allowed size-limited videos instead.​

☆PhistucK