Clean up third_party/libpng/pngusr.h and update it for libpng-1.2.44.

Clean up third_party/libpng/pngusr.h and update it for libpng-1.2.44.

Defined PNG_NO_READ_SWAP, PNG_NO_WRITE_SWAP, PNG_NO_READ_oFFs, PNG_NO_WRITE_oFFs,
PNG_NO_USER_LIMITS, PNG_NO_SET_USER_LIMITS, PNG_NO_TIME_RFC1123.
Clarified that PNG_NO_INFO_IMAGE, PNG_NO_PROGRESSIVE_READ are undefined.
Used PNG_NO_SEQUENTIAL_READ instead of PNG_NO_SEQUENTIAL_READ_SUPPORTED.

Defined PNG_NO_WRITE_gAMA, PNG_NO_WRITE_sRGB.
Clarified that PNG_NO_READ_gAMA and PNG_NO_READ_sRGB are undefined
(i.e. gAMA and sRGB are retrieved by libpng, along with iCCP).

Fixed typo in the mangling of png_set_text_2.
Renamed the prefix webkit_ to wk_ in mangled names.
Restored the full function name in mangling; e.g., png_create_read_struct
is mangled as wk_png_create_read_struct instead of wk_png_cr_read_str.

Added mangling for all symbols with external linkage that are never macros.
Added explicit #undef for symbols that may sometimes be macros in png.h:
png_benign_error, png_chunk_benign_error, png_get_int_32, png_get_uint_16,
png_get_uint_32, png_info_init, png_read_init, png_write_init.

BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=68873

[Nico, 2010-12-10 01:02:33]

Rubber-stampy LG

Have you tested with both big- and little-endian pngs with 16bit/channel?

[Cosmin Truta, 2010-12-10 03:33:41]

On 2010/12/10 01:02:33, Nico wrote:
> Have you tested with both big- and little-endian pngs with 16bit/channel?

PNG is all big-endian. There are no little-endian multi-byte samples or chunk
data.

As an exception to the big-endian-everywhere rule, the zlib/deflate streams are
little-endian, but deflate is specified outside of PNG. The PNG spec pretends
not to know what's inside deflate streams.

[Nico, 2010-12-10 03:37:38]

On Thu, Dec 9, 2010 at 7:33 PM,  <ctruta@chromium.org> wrote:
> Reviewers: Nico,
>
> Message:
> On 2010/12/10 01:02:33, Nico wrote:
>>
>> Have you tested with both big- and little-endian pngs with 16bit/channel?
>
> PNG is all big-endian. There are no little-endian multi-byte samples or
> chunk data.

PNG is such a sane format!

I take it this means you did test big-endian multi-byte samples.

>
> As an exception to the big-endian-everywhere rule, the zlib/deflate streams
> are
> little-endian, but deflate is specified outside of PNG. The PNG spec
> pretends
> not to know what's inside deflate streams.
>
>
> Description:
> Clean up third_party/libpng/pngusr.h and update it for libpng-1.2.44.
>
> Defined PNG_NO_READ_SWAP, PNG_NO_WRITE_SWAP, PNG_NO_READ_oFFs,
> PNG_NO_WRITE_oFFs,
> PNG_NO_USER_LIMITS, PNG_NO_SET_USER_LIMITS, PNG_NO_TIME_RFC1123.
> Clarified that PNG_NO_INFO_IMAGE, PNG_NO_PROGRESSIVE_READ are undefined.
> Used PNG_NO_SEQUENTIAL_READ instead of PNG_NO_SEQUENTIAL_READ_SUPPORTED.
>
> Defined PNG_NO_WRITE_gAMA, PNG_NO_WRITE_sRGB.
> Clarified that PNG_NO_READ_gAMA and PNG_NO_READ_sRGB are undefined
> (i.e. gAMA and sRGB are retrieved by libpng, along with iCCP).
>
> Fixed typo in the mangling of png_set_text_2.
> Renamed the prefix webkit_ to wk_ in mangled names.
> Restored the full function name in mangling; e.g., png_create_read_struct
> is mangled as wk_png_create_read_struct instead of wk_png_cr_read_str.
>
> Added mangling for all symbols with external linkage that are never macros.
> Added explicit #undef for symbols that may sometimes be macros in png.h:
> png_benign_error, png_chunk_benign_error, png_get_int_32, png_get_uint_16,
> png_get_uint_32, png_info_init, png_read_init, png_write_init.
>
> BUG=none
> TEST=none
>
> Please review this at http://codereview.chromium.org/5689001/
>
> SVN Base: http://git.chromium.org/git/chromium.git@trunk
>
> Affected files:
>  M third_party/libpng/pngusr.h
>
>
>

[Cosmin Truta, 2010-12-10 03:45:04]

On 2010/12/10 01:02:33, Nico wrote:
> Have you tested with both big- and little-endian pngs with 16bit/channel?

I would like to add that there is no 16-bit sample handling code in WebKit or
Chromium. This is done inside libpng. All that's done by WebKit (inside
WebCore/platform/image-decoders/png/PNGImageDecoder.cpp) and Chromium (inside
gfx/codec/png_codec.cc) is the following:

  if (bitDepth == 16)
    png_set_strip_16(png);

[Nico, 2010-12-10 03:50:17]

On Thu, Dec 9, 2010 at 7:45 PM,  <ctruta@chromium.org> wrote:
> On 2010/12/10 01:02:33, Nico wrote:
>>
>> Have you tested with both big- and little-endian pngs with 16bit/channel?
>
> I would like to add that there is no 16-bit sample handling code in WebKit
> or
> Chromium. This is done inside libpng. All that's done by WebKit (inside
> WebCore/platform/image-decoders/png/PNGImageDecoder.cpp) and Chromium
> (inside
> gfx/codec/png_codec.cc) is the following:
>
>  if (bitDepth == 16)
>    png_set_strip_16(png);

Yes, that's something I know for a change :-) But since you're
changing the png config, I figured checking if 16bit pngs won't hurt.
(Then again, I don't know the libpng code and I'm not sure if this
codepath is affected by your config changes. It's conceivable to me at
least, and checking if it still works is as easy as opening
http://www.libpng.org/pub/png/PngSuite/basn0g16.png

[Cosmin Truta, 2010-12-10 03:57:22]

On 2010/12/10 03:37:38, Nico wrote:
> PNG is such a sane format!

You can say that again! I joined the PNG team because I found the design
extremely simple and elegant. Too bad that the follow-on MNG format had none of
that simplicity, and it flopped.

libpng, is, in stark contrast, extremely arcane. It's trying to satisfy too many
requirements IMHO.

> I take it this means you did test big-endian multi-byte samples.

Sorry, but no... I only built and tested the change in isolation, in my own
libpng development/testing environment. The Chromium build on my only two
machines (Ubuntu desktop and Mac laptop) use the system-supplied libpng, not the
third_party one. Besides, I can no longer use the trybots, until I am a
committer...

[Nico, 2010-12-10 17:38:31]

On Thu, Dec 9, 2010 at 7:57 PM,  <ctruta@chromium.org> wrote:
> On 2010/12/10 03:37:38, Nico wrote:
>>
>> PNG is such a sane format!
>
> You can say that again! I joined the PNG team because I found the design
> extremely simple and elegant. Too bad that the follow-on MNG format had none
> of
> that simplicity, and it flopped.
>
> libpng, is, in stark contrast, extremely arcane. It's trying to satisfy too
> many
> requirements IMHO.
>
>> I take it this means you did test big-endian multi-byte samples.
>
> Sorry, but no... I only built and tested the change in isolation, in my own
> libpng development/testing environment. The Chromium build on my only two
> machines (Ubuntu desktop and Mac laptop) use the system-supplied libpng, not
> the third_party one. Besides, I can no longer use the trybots, until I am a
> committer...

I patched in your CL, looks like 16bit images still work. I also sent
it to the trybots, they all came back green.

I will land this CL for you some time today unless I hear otherwise.