170352 - Upgrade mozilla libpng to 1.2.5

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[tor]

libpng 1.2.5 fixes numerous reported PNG problems.  I've been testing
with 1.2.5rc3 without problems so far.

Placeholder until 1.2.5 goes final.

Comment 1

[Glenn Randers-Pehrson]

Libpng version 1.2.5 is due out on 2 October 2002, barring any significant
bug reports against version 1.2.5rc3.

Glenn

Comment 2

[tenthumbs]

Bug 169392 probably depends on this one too.

Comment 3

[Glenn Randers-Pehrson]

Libpng-1.2.5 is available for your downloading pleasure
from http://libpng.sf.net  ...Glenn

Comment 4

[tor]

libpng-1.2.5 also works fine with mozilla, passes all the png test suites,
and appears to fix the various dependent bugs.

Comment 5

[tor]

Attachment: unix/win32 png build change (disable write support to shrink library)

Comment 6

[Glenn Randers-Pehrson]

> disable write support

Good idea.    ...Glenn

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

> disable write support

hm, is that possible for the jpeg library mozilla is using as well?

Comment 8

[Kathleen :Brade]

I mentioned to tor that for Mac, the #define would go in:
  mozilla/build/mac/build_scripts/MozillaBuildFlags.txt

Comment 9

[tor]

Attachment: attempt at similar mac build change

Comment 10

[Glenn Randers-Pehrson]

>> disable write support

>hm, is that possible for the jpeg library

Doesn't seem so.  Neither for zlib.   ...Glenn

Comment 11

[tor]

Attachment: mac build change to disable write support in libpng

Comment 12

[tor]

Bah - I was looking at the size of the intermediate libpng, not the resulting
libimglib2.  The linker is smart enough to throw away the unused write code.

Comment 13

[tor]

Attachment: bump MOZPNG in configure.in

Comment 14

[hacker formerly known as [e-mail]]

Comment on attachment 101603 [details] [diff] [review]
bump MOZPNG in configure.in

r=cls

Comment 15

[Glenn Randers-Pehrson]

> linker is smart

Right.  There probably won't be much change in the size of the executable because
the read and write stuff is pretty well separated in libpng.  Compiling and
linking might be a little faster, and the png_struct and will be something like
48 bytes smaller so there will be some (perhaps negligible) savings in memory
resource usage per image.  You can entertain yourself by logging  
sizeof(png_struct) like we do in pngtest.

...Glenn

Comment 16

[tor]

Checked in.

Comment 17

[tor]

*** Bug 160453 has been marked as a duplicate of this bug. ***

Comment 18

[tor]

*** Bug 169105 has been marked as a duplicate of this bug. ***

Comment 19

[tor]

*** Bug 169392 has been marked as a duplicate of this bug. ***