Closed Bug 11019 Opened 21 years ago Closed 21 years ago
PNG images no longer display; GIFs and JPEGs extremely slow
CVS -A pull from around 19990730 21:30; just trying to get my sources up to date. In addition to some major layout regression (see <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=11018">bug 11018</A>), XPCOM and/or imagelib has regressed (possibly related to Necko): GIFs and JPEGs are extremely slow to load (~20 seconds from display of pink toucan JPEG image at above URL until tiny GIF icons at the bottom display), and PNGs never load. There are no obvious error messages related to libpng, libnspng or libimg.so. System is Linux 2.0.36, libc5, gcc 18.104.22.168, P100, clobber_all build, configure with no options. Greg Roelofs
Greg: Try pulling a fresh tree. -pn
Hi, Pamela, You mean fresher than yesterday (3 August)? I did a complete clobber_all build yesterday morning; no build errors, but also no change in either this or the file/ftp/resource problem (bug 11018). My best guess right now is that it's somehow libc5-related, but I only know one other person who compiles on a Linux/libc5 system, and he's still waiting for Necko to settle. I take it your Win32 and Linux builds still display PNGs OK?
linux pull from 08-03-99, 17:20 works fine for me. No one else has reported experiencing the same problem.
OK, feel free to mark it WORKSFORME. If and when I can confirm the problem in someone else's build and/or find some clues in my own, I'll reopen. Btw, was your build using a system libpng or one built by Mozilla?
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
My local linux build uses native png and jpeg libs. I don't know what the tinderbox builds use. If your png lib version is very current, it may be confusing the autoconfig system.
I haven't had any problems; since Greg is happy with the current state, rubber- stamping as Verified-WORKSFORME.
I discovered that PNG images work fine with my version of the PNG code, and after splitting my changes into a series of patches (http://pobox.com/~newt/test/moz/), it turns out the cause is the same as that for the first half of 3195: Mozilla's use and/or modification of an internal libpng buffer. I'm tentatively scheduled to do a pngcom mini-carpool on Tuesday (with dp) that will include the fix. I'll leave the status alone... Greg
My pngcom fixes were checked in on 9 September, so now it works for me, too. Greg
You need to log in before you can comment on or make changes to this bug.