[blink-dev] Intent to Implement: Animated PNG

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

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

seb mitchell

2015-08-02 23:15:24 UTC

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

Post by Max Stepin
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
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

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

Eric Bidelman

2015-08-03 01:19:19 UTC

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

Post by 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

To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-08-03 05:50:39 UTC

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.

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

Post by Max Stepin
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
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

To unsubscribe from this group and stop receiving emails from it, send an

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

PhistucK

2015-08-03 06:53:32 UTC

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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at this
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is almost
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
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.

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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it, send

To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-08-03 10:10:13 UTC

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/

Post by 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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at this
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is almost
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
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.

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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it, send

To unsubscribe from this group and stop receiving emails from it, send an

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

PhistucK

2015-08-03 10:23:48 UTC

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

â*PhistucK*

Post by 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
http://littlesvr.ca/apng//inter-frame.html
https://codereview.chromium.org/1250373006/

Post by 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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at this
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is almost
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
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.

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

Post by 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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it, send

To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-08-03 10:41:41 UTC

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

Post by 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*

Post by 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
http://littlesvr.ca/apng//inter-frame.html
https://codereview.chromium.org/1250373006/

Post by 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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at this
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is almost
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
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.
On Mon, Aug 3, 2015 at 4:19 AM, Eric Bidelman <

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

Post by 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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it,

To unsubscribe from this group and stop receiving emails from it, send

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

PhistucK

2015-08-03 10:50:07 UTC

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*

Post by 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..
Balancing "moving the web forward" and "compatibility risk"
Blink's willingness to accept a change is largely determined by the
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

Post by 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*

Post by 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
https://codereview.chromium.org/1250373006/

Post by 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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is almost
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
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.
On Mon, Aug 3, 2015 at 4:19 AM, Eric Bidelman <

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

Post by 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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it,

To unsubscribe from this group and stop receiving emails from it, send

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

Max Stepin

2015-08-03 11:11:10 UTC

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

Post by Max Stepin
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.

Post by Max Stepin
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*

Post by 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..
Balancing "moving the web forward" and "compatibility risk"
Blink's willingness to accept a change is largely determined by the
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

Post by 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*

Post by 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
https://codereview.chromium.org/1250373006/

Post by 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*

Post by Max Stepin
Edge.devs told me they don't have plans for additional formats "at
https://twitter.com/MSEdgeDev/status/596197829414035456
A few technical details about proposed implementation (which is
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
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.
On Mon, Aug 3, 2015 at 4:19 AM, Eric Bidelman <

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

Post by 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

Post by Max Stepin
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

To unsubscribe from this group and stop receiving emails from it,

To unsubscribe from this group and stop receiving emails from it, send

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

Philip Jägenstedt

2015-08-03 15:07:54 UTC

Post by Max Stepin
If a change has low compatibility risk but isn't expected to significantly

Post by Max Stepin
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

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

PhistucK

2015-08-03 16:30:15 UTC

Post by Philip JÃ¤genstedt

Animated WebP is supported.
http://littlesvr.ca/apng/images/GenevaDrive.webp

â*PhistucK*

Post by Max Stepin
If a change has low compatibility risk but isn't expected to

Post by Max Stepin
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.
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

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

'Peter Kasting' via blink-dev

2015-08-03 19:16:12 UTC

Post by Max Stepin
If a change has low compatibility risk but isn't expected to significantly

Post by Max Stepin
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

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

'Chris Blume' via blink-dev

2015-08-03 21:07:53 UTC

As I understand it, Mozilla is implementing WebP support
<https://bugzilla.mozilla.org/show_bug.cgi?id=856375>.
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
<http://caniuse.com/#feat=apng>.

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 | ***@google.com | +1-614-929-9221

On Mon, Aug 3, 2015 at 12:16 PM, 'Peter Kasting' via blink-dev <

Post by Max Stepin
If a change has low compatibility risk but isn't expected to

Post by Max Stepin
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
* 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
To unsubscribe from this group and stop receiving emails from it, send an

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

'Brandon Jones' via blink-dev

2015-08-03 21:25:47 UTC

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?

On Mon, Aug 3, 2015 at 2:08 PM 'Chris Blume' via blink-dev <

Post by 'Chris Blume' via blink-dev
As I understand it, Mozilla is implementing WebP support
<https://bugzilla.mozilla.org/show_bug.cgi?id=856375>.
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
<http://caniuse.com/#feat=apng>.
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.
On Mon, Aug 3, 2015 at 12:16 PM, 'Peter Kasting' via blink-dev <

Post by Max Stepin
If a change has low compatibility risk but isn't expected to

Post by Max Stepin
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
* 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

To unsubscribe from this group and stop receiving emails from it, send an

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

PhistucK

2015-08-04 05:39:49 UTC

Post by 'Chris Blume' via blink-dev
As I understand it, Mozilla is implementing WebP support
<https://bugzilla.mozilla.org/show_bug.cgi?id=856375>.

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*

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

Anne van Kesteren

2015-08-04 06:33:45 UTC

On Mon, Aug 3, 2015 at 11:07 PM, 'Chris Blume' via blink-dev

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/

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

p***@gmail.com

2015-08-22 04:32:20 UTC

Post by 'Chris Blume' via blink-dev
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

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

'Chris Blume' via blink-dev

2015-08-23 01:48:58 UTC

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.

Post by 'Chris Blume' via blink-dev
Also as I understand it, WebP gives better compression most of the time

Post by 'Chris Blume' via blink-dev
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?
http://littlesvr.ca/apng/gif_apng_webp.html
To unsubscribe from this group and stop receiving emails from it, send an

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

'Chris Blume' via blink-dev

2015-08-23 01:54:31 UTC

Oh and as far as research to back up the claim, there are both lossless vs.
png
<https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study>
and lossy vs. jpeg
<https://developers.google.com/speed/webp/docs/webp_study> comparisons. The
lossless vs. png comparison is for non-animated content, however.

Post by 'Chris Blume' via blink-dev
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.

Post by 'Chris Blume' via blink-dev
Also as I understand it, WebP gives better compression most of the time

Do you have any research to back up this assumption?
http://littlesvr.ca/apng/gif_apng_webp.html
To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-08-23 15:21:57 UTC

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".

Post by 'Chris Blume' via blink-dev
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.

Post by 'Chris Blume' via blink-dev
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

Post by 'Chris Blume' via blink-dev
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.

Post by 'Chris Blume' via blink-dev
+1-614-929-9221

Post by 'Chris Blume' via blink-dev
Also as I understand it, WebP gives better compression most of the time

Do you have any research to back up this assumption?
http://littlesvr.ca/apng/gif_apng_webp.html
To unsubscribe from this group and stop receiving emails from it, send an

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

Dmitry Azaraev

2015-08-24 01:02:02 UTC

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

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

Pascal Massimino

2015-08-24 03:48:38 UTC

Hi,

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".

Post by 'Chris Blume' via blink-dev
Those images happen to be images that afford APNG several benefits. For
example, there are no full-frame updates.

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/

Post by 'Chris Blume' via blink-dev

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
55 874 090 bytes
https://drive.google.com/file/d/0B87CElpmcFpPV2VPMkJ0VENlN2s/view
72 526 230 bytes
https://drive.google.com/file/d/0B87CElpmcFpPQ0kwMjFiUDhXbE0/view
53 579 128 bytes
https://drive.google.com/file/d/0B87CElpmcFpPenpDOTRDWERVV3M/view
49 158 595 bytes
https://drive.google.com/file/d/0B87CElpmcFpPSnpJNzlHcVFqN2M/view

Post by 'Chris Blume' via blink-dev
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.

Post by 'Chris Blume' via blink-dev
Also as I understand it, WebP gives better compression most of the time

Do you have any research to back up this assumption?
http://littlesvr.ca/apng/gif_apng_webp.html
To unsubscribe from this group and stop receiving emails from it, send

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

Max Stepin

2015-08-04 06:21:45 UTC

Post by 'Peter Kasting' via blink-dev
I don't make the final call here, but I'll reiterate the concerns I think
* 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

Post by 'Peter Kasting' via blink-dev
* 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

Post by 'Peter Kasting' via blink-dev
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

Post by 'Peter Kasting' via blink-dev
* 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.

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

seb mitchell

2015-08-04 07:19:25 UTC

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.

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

'Peter Kasting' via blink-dev

2015-08-04 19:03:54 UTC

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

Post by Max Stepin
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.

Post by Max Stepin
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

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

Max Stepin

2015-08-04 20:43:05 UTC

Post by 'Peter Kasting' via blink-dev
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?

Post by 'Peter Kasting' via blink-dev
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.

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

'Chris Blume' via blink-dev

2015-08-04 21:06:47 UTC

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.

Post by 'Peter Kasting' via blink-dev
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?

They are not exercising that option. I don't see artists creating animated
webp files, at all.
The numbers are probably in single digits.
To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-08-04 21:35:54 UTC

Post by 'Chris Blume' via blink-dev
Keep in mind that other larger organizations such as Facebook and Netflix
are using WebP.

They are not using *animated* WebP though.

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

Elliott Sprehn

2015-08-05 22:27:51 UTC

Does mobile Safari support APNG today?

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

Mike Lawther

2015-08-06 00:00:06 UTC

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

Post by Elliott Sprehn
Does mobile Safari support APNG today?

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

Rik Cabanier

2015-08-06 04:13:14 UTC

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

Post by Elliott Sprehn
Does mobile Safari support APNG today?

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

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

Noel Gordon

2015-08-06 04:54:59 UTC

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

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

Post by Elliott Sprehn
Does mobile Safari support APNG today?

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

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

Rik Cabanier

2015-08-06 05:44:23 UTC

Post by 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.

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.

Post by Noel Gordon
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

Post by Noel Gordon

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

Post by Elliott Sprehn
Does mobile Safari support APNG today?

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

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

'Noel Gordon' via blink-dev

2015-08-06 12:53:33 UTC

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.

Post by Noel Gordon
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

Post by Noel Gordon

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

Post by Elliott Sprehn
Does mobile Safari support APNG today?

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

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

Mike Lawther

2015-08-06 23:40:57 UTC

Post by Rik Cabanier
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.

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

Max Stepin

2015-08-06 06:09:10 UTC

Post by Noel Gordon
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?

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

Noel Gordon

2015-08-06 13:03:44 UTC

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

~noel

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

Max Stepin

2015-08-06 20:44:51 UTC

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.

Post by Noel Gordon

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

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

Max Stepin

2015-08-25 06:30:08 UTC

Post by 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.

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?

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

'Peter Kasting' via blink-dev

2015-08-25 06:42:45 UTC

Post by 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.

OK, I ran this demo for a while to collect the stats on 100 000 frames
http://littlesvr.ca/apng/gif_apng_webp1.html
I measured the time spent inside *decode(index)* call from *ImageDecoder::frameBufferAtIndex(size_t
index)*
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

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

Philip Jägenstedt

2015-09-16 07:51:47 UTC

On Tue, Aug 25, 2015 at 8:42 AM, 'Peter Kasting' via blink-dev <

Post by 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.

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.

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

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

'Peter Kasting' via blink-dev

2015-09-16 21:25:19 UTC

Post by Philip JÃ¤genstedt
On Tue, Aug 25, 2015 at 8:42 AM, 'Peter Kasting' via blink-dev <

Post by 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.

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.

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.

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

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

Mike Lawther

2015-09-23 00:44:15 UTC

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

Post by Philip JÃ¤genstedt
On Tue, Aug 25, 2015 at 8:42 AM, 'Peter Kasting' via blink-dev <

Post by 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.

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.

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.

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

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

Yoav Weiss

2015-09-23 08:43:52 UTC

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)

Post by 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

Post by Philip JÃ¤genstedt
On Tue, Aug 25, 2015 at 8:42 AM, 'Peter Kasting' via blink-dev <

Post by 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.

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.

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.

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

To unsubscribe from this group and stop receiving emails from it, send an

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

Max Stepin

2015-09-23 10:01:33 UTC

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

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

Post by 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)

Post by 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

Post by Philip JÃ¤genstedt
On Tue, Aug 25, 2015 at 8:42 AM, 'Peter Kasting' via blink-dev <

Post by 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.

OK, I ran this demo for a while to collect the stats on 100 000
http://littlesvr.ca/apng/gif_apng_webp1.html
I measured the time spent inside *decode(index)* call from *ImageDecoder::frameBufferAtIndex(size_t
index)*
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.

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.

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

To unsubscribe from this group and stop receiving emails from it, send an

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

Anne van Kesteren

2016-08-11 07:05:36 UTC

Post by Mike Lawther
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/
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

Mike Lawther

2016-08-11 07:10:57 UTC

Thanks for the heads up Anne!

Post by Mike Lawther
We've been having discussions with some folks at Mozilla to make sure

that

Post by Mike Lawther
if we go ahead with this, that Chrome and Firefox will be consistent in

what

Post by Mike Lawther
we present to web developers. Quite recently Mozilla registered a new

MIME

Post by Mike Lawther
type (http://www.iana.org/assignments/media-types/image/vnd.mozilla.apng

Post by Mike Lawther
and we see how this is used as critically important for APNG. Web

developers

Post by Mike Lawther
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.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+***@chromium.org.

'Peter Kasting' via blink-dev

2016-08-11 07:43:14 UTC

Post by Mike Lawther
We've been having discussions with some folks at Mozilla to make sure

that

Post by Mike Lawther
if we go ahead with this, that Chrome and Firefox will be consistent in

what

Post by Mike Lawther
we present to web developers. Quite recently Mozilla registered a new

MIME

Post by Mike Lawther
type (http://www.iana.org/assignments/media-types/image/vnd.mozilla.apng

Post by Mike Lawther
and we see how this is used as critically important for APNG. Web

developers

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

'Peter Kasting' via blink-dev

2015-08-03 06:57:08 UTC

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

PK

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

Paweł Hajdan, Jr.

2015-08-03 09:36:13 UTC

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Å

On Mon, Aug 3, 2015 at 8:57 AM, 'Peter Kasting' via blink-dev <

Post by 'Peter Kasting' via blink-dev
This has been explicitly refused for inclusion in Blink repeatedly.
What's changed to lead to proposing it again?
PK

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

Max Stepin

2016-02-23 15:06:14 UTC

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:

Loading Image...

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.

s***@gmail.com

2016-02-28 02:06:29 UTC

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

OlegM

Mike Lawther

2016-02-28 22:04:47 UTC

There is no timeframe.

Post by s***@gmail.com
So, what's the timeframe for the final decision according to your
regulations? Product management is not Congress to play filibusters.
OlegM

s***@gmail.com

2016-02-28 22:58:25 UTC

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

OlegM

Post by Mike Lawther
There is no timeframe.

Post by s***@gmail.com
So, what's the timeframe for the final decision according to your
regulations? Product management is not Congress to play filibusters.
OlegM

Max Stepin

2016-06-30 17:43:43 UTC

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

2016-07-19 18:26:21 UTC

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

Post by Max Stepin
APNG is getting more popular (at least in Japan), as Line messenger
https://creator.line.me/en/guideline/animationsticker/
https://developer.apple.com/reference/messages
Thanks to all that Japan traffic, downloads for my small APNG creation
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.

x***@gmail.com

2016-07-19 18:52:49 UTC

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

Max Stepin

2016-11-21 06:10:23 UTC

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.

joostouwerling via blink-dev

2016-11-23 21:59:51 UTC

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.

Post by Max Stepin
So now we have 2 implementations? Well, OK. :)
https://codereview.chromium.org/1567053002/
https://codereview.chromium.org/2386453003/
Max.

Max Stepin

2016-11-24 05:43:27 UTC

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.

Post by joostouwerling via blink-dev
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.

Post by Max Stepin
So now we have 2 implementations? Well, OK. :)
https://codereview.chromium.org/1567053002/
https://codereview.chromium.org/2386453003/
Max.

joostouwerling via blink-dev

2016-11-25 18:36:26 UTC