Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Chrome should use PNG instead of GIF for still images



Core Graveyard
18 years ago
9 years ago


(Reporter: Roland Mainz, Assigned: Glenn Randers-Pehrson)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(14 attachments)

237.58 KB, application/octet-stream
7.02 KB, application/octet-stream
33.53 KB, image/jpeg
241.97 KB, application/octet-stream
218.26 KB, application/octet-stream
1019 bytes, text/plain
289.66 KB, application/octet-stream
9.64 KB, video/x-mng
3.08 KB, video/x-mng
43.71 KB, video/x-mng
3.89 KB, video/x-mng
15.31 KB, video/x-mng
200.00 KB, application/octet-stream
180.36 KB, application/octet-stream


18 years ago
Long ago there was a PNG hype and the good (PNG, free) vs. bad (GIF, owned by
Unisys) war...

Two simple questions:
- Why producing a project under GLP which still uses GIF for it's chrome ?
- Why not moving from GIF to PNG ?

Pro PNG:
- Less space on disk
- No GIF license fee
- 24-bit colors for chrome

Contra PNG:
- Requires to start a converter which converts GIF -> PNG for each image =:-)
- Struggle with some (possible) bugs in the PNG decoder part


18 years ago
Target Milestone: M15

Comment 1

18 years ago
Let's get the browser robust first.


18 years ago
Assignee: don → pnunn
Component: Apprunner → ImageLib
QA Contact: leger → elig

Comment 2

18 years ago
Updating QA Contact


18 years ago
Last Resolved: 18 years ago
Resolution: --- → LATER


18 years ago

Comment 3

18 years ago
reopening and moving to dawn, since she's actually tested


18 years ago
Assignee: pnunn → endico

Comment 4

18 years ago
You've tested them.
You have my vote.....but first you should check with
who ever owns the resource files. They aren't in my domain.


18 years ago

Comment 5

18 years ago
i've tested my png chrome files on linux. need testers for mac and windows.
See my postings in mozilla.xpfe today and yesterday. Images and updated
xul/css files are at  spitzer
will be checking them in tonight.


18 years ago
Resolution: LATER → ---

Comment 6

18 years ago


18 years ago
Depends on: 6323
Target Milestone: M15 → M9

Comment 7

18 years ago
adding dependency on bug 6323. jpeg and png images don't display on freebsd.
changing milestone to match 6323

Comment 8

18 years ago
how we comin' on this.  at this point if its not ready
we should most likely try and get in during early M10.

Comment 9

18 years ago
I think it is a mistake to push this through. Let's keep
the gif chrome and migrate to png when some build issues
are resolved.  Why couldn't this is set to LATER? Let's
focus on some of the problem that affect functionality....

Comment 10

18 years ago


18 years ago
Target Milestone: M9 → M10

Comment 11

18 years ago
I agree with Pam. PNG is wobbly enough on other platforms that this change could
possibly completely break them. Plus, alpha channels on unix is a long way off.
Moving this to m10 for now to remind me to set up png chrome for people to play
with  by hand, but not it make the default. After that's done, I'll later the


18 years ago
Last Resolved: 18 years ago18 years ago
Resolution: --- → LATER

Comment 12

18 years ago
Thanks to Steve Morrison from Mozillazine for creating a png theme and adding it
to the Chrome Zone.Lets use this theme instead of moving the entire browser to
png until we're sure png works on all platforms. We don't want the entire gui
rendering as single dots. =)  Marking this as LATER.

Comment 13

18 years ago

What about the idea that Mozilla's nightly builds are shipped with multiple
chromes ?
What about a text-only chrome ?

Comment 14

18 years ago
Is it still? I didn't think it worked. I just looked at my aug23 build and
I don't see the chrome switch menu item there any more. I vaguely remember
that the older chrome zone themes were checked in. If so, then maybe steve
could get the new png one checked in too and contact to
get instructions on using it into the release notes?


18 years ago

Comment 15

18 years ago
Steve Morrison rocks! Verifying later.
Reopening, seeing as now is later ;-)

Seriously, I had a look through the open PNG bugs and it seems we are in pretty 
good shape. Is there anything to prevent us switching to an all-PNG chrome at 
the moment?

Resolution: LATER → ---
Target Milestone: M10 → M20

Comment 17

17 years ago
The only problem I can think of is the lack of mng support, bug 18574 , would
mean the throbber would have to remain an animated gif.

Comment 18

17 years ago
The PNG theme on MozillaZine is so old it's worthless, so last night I started
working on an all png replacement based on the latest nightly (2000052908). So
far I've found two bugs that block going to an all png chrome.

bug 18574 ,which I mentioned last night. There are 3 animated gifs in
chrome/skins/modern/global/skin. loading.gif animthrob.gif and progressmeter-

bug 19283 Windows tranparancy. There are a lot of gifs with transparent
backgrounds in chrome. As an example in Navigator the back, forward, reload, and
stop symbols show up as White boxes with the symbol inside.

I have no permission bits :-( . Could someone please set dependancy on these bugs.

When I finish converting all the chrome I'll submit it to MozillaZine's New

Comment 19

17 years ago
I think the correct thing to do now with this is to png based skin get
people to try it out, and if it works well on all platforms then eventually
get it in as the default skin.

I would give up on the notion of using animated PNGs though since no one
has expressed any interested in implementing it. Reassigning this to 
Dobbins since he expressed an interest in making a PNG skin.
Assignee: endico → dobbinsj
Depends on: 19283

Comment 20

17 years ago
taking myself off the cc: list.
I'm interested, but I'm drowning in email.

Comment 21

17 years ago

Comment 22

17 years ago
See bug 6963 (WFM) and bug 38638 (LATER).

Comment 23

17 years ago
I have changed all non-animated gifs in the chrome directory to pngs. This
includes the modern skin, the skin for Chatzilla, and the Mozilla logo for the :
about page. After a week of testing on Win 98 and Red Hat Linux 6.2, I submitted
the changes to The New ChromeZone on 6/11/2000. As of now it hasn't been posted,
so I will attach it to this bug. It is based on the latest nightlys in the M16
Win 98 test- no noticible loss in performance. Looks like hell due to bug 19283
Linux test- can't tell any differance between png and gif based skin.
Mac test- I don't have one :-( Need some help here.

Comment 24

17 years ago
Created attachment 10101 [details]
PNG Based Modern Skin

Comment 25

17 years ago
Looks pretty good on WinNT 4 sp6a.  Well, let me rephrase that.  It looks as
good as can be expected without transparency.

Comment 26

17 years ago
Created attachment 10367 [details]
Alpha-channel .png buttons.

Comment 27

17 years ago
Created attachment 10368 [details]
Screenshot of the alpha-channel .png buttons

Comment 28

17 years ago
I'm most regretful of all the spam I must be sending - this is the first time
I've used bugzilla. Anyway, the first new attachment is a .tar.gz that I
extract over nightly build tarballs. It contains a bunch of 24-bit alpha
channel .png files which replace the backgrounds on the four browser toolbar
buttons and the few in Mozilla Mail and Composer. Chief advantages over the
raw .gif images are that there's no dithering artifacts, and that the
"button disabled" images is actually 50% opaque, rather than stripy.

I've also attached a small (~35 KB) .jpg screenshot of the very browser
window I'm typing this comment in. :)

Comment 29

17 years ago
BTW: Does Mozilla 5 ship with a B/W-skin per default (one-bit deep !!) or should
I file a RFE for this ?

Comment 30

17 years ago
On MacOS9 using MN16 final the package looks as good as can be expected and I
haven't found any problems.

Comment 31

17 years ago
I do not understand the reason behind this bug.  I do not currently have any 
desire to see these files changed from GIF files to PNG.  I would like to be 
convinced that there is a serious advantage to this before allowing such a change 
to the Modern Skin.

Comment 32

17 years ago
I'm really concerned about checking in PNG at this point - we all want to ship 
this baby, and switching to PNG sounds like a good way to introduce all kinds of 
new bugs and problems with the PNG decoder, etc.  

It also sounds like we are not just creating the same chrome in PNG vs gif, but 
we are creating a new chrome with a different set of buttons and behaviors. 
Won't this create havok for the gang working on skins because then they would 
have to support and be able to skin multiple UIs?

The timing and risks are bad, and the benefit doesn't seem strong enough at this 
point in the project.  Can we branch and/or do this later, *after* we complete 
the gif based UI and get switching skins to work?
I am unaware of the current state of PNG support in Mozilla. Everything image 
I've loaded has looked fine, but admittedly I've mostly been dealing with 
screenshots and not transparent images. Most chrome graphics use 1-bit 
transparency for icons, or no transparency for things like background images. 
Before checking in a complete patch, one would have to be certain that 

a) it was supported on all platforms (that's right, *ALL* of them, we have to 
maintain the LCD & portability)
b) there was no significant performance degradation on real world hardware.
c) there was *extensive* testing (probably the easiest way to go about 
something like this would be to apply incrementally, test, wait for people to 
squeal, then proceed with caution...)

That said, I have no problem seeing a PNG version of Modern if someone wants to 
go to the effort of creating the graphics and checking it all in. 
> PNG sounds like a good way to introduce all kinds of
> new bugs and problems with the PNG decoder, etc.

No product should ship with a broken PNG decoder.  PNG has been around for years
now, there are no excuses.  If this leads to bugs, it can only be a good thing.

Reasons why this should be done that come to mind:

(a) free software, free format
(b) PNGs are smaller and probably therefore faster due to the CPU/hard disk
access time disparity (don't quote me on that)
(c) the presence of PNG will make people realise that PNG works and therefore
start to use alpha and gamma in their skins

Comment 35

17 years ago
Well, no arguments any more - wrote them all.

OK, simple salomonian judgement:
Make the PNG skin the default _NOW_ and keep it until a few weeks after M17
release. If there are too much problems after M17 release: Switch back to GIF
(and send Unisys $1 per downloaded Mozilla archive =:-)

Comment 36

17 years ago
Hey John, unfortunately i took most of the png's out of Aphrodite because of
previous platform specific problems.

However, if you run the current version on Windows, the grippies transparent
background which are still png's are black. So i would say there is 
still a problem. I think they are fine on the mac.

The png images were created with Gimp.


Comment 37

17 years ago
Adding dependancy on bug 18574 per John Dobbins' request on May 30th (oops).

It seems MNG support is in, and bug 19283 (the problem Pete mentions) is being 
worked on.
Depends on: 18574

Comment 38

17 years ago
A few points,
1) I do not intend to even try this untill after NS Beta 2 forks. It is too 
close to risk any new bugs.
2) There is no way this can be fully implimented untill after all Windows 
transparancy problems are solved. This means bug 19283 for binary transparancy, 
and bug 36694 for alpha transparancy.
3) Even if there were no blocking bugs, There are a lot of changes to be 
checked in. It's not going to happen all at once.

Comment 39

17 years ago
Someone should probably add bug 36694 as a blocker of this then, right?

Comment 40

17 years ago
I understand the general concerns you mention with the GIF format, I don't like 
it myself because of the surrounding aura of "proprietaryness". However 
the 'modern' skin was entirely created in-house with properly licensed tools, 
and according to the legal powers in the company here there are no problems to 
be expected with this approach.

While I fully understand the benefits of PNG, for this low color iteration of 
the modern skin I don't think its worth the effort changing all image and CSS 
files, but other skins will likely use PNG for higher color rendering. For 8-
bit palette images with transparency compression ratios and performance are 
about on par between GIFs and PNGs, that is what we are using for the modern 
skin to play within the web safe palette. In addition since you started the 
effort, quite a few of the icons and other images have already been changed and 
updated, so I do not feel its worth the effort changing things again. Also the 
rendering of the GIF format in the part has been more stable across all 
platforms we support (not just Mac,Win32, Linux but also other Unixes), thus it 
makes a good format a base skin. Finally animations can only be produced in GIF 
right now (that is until we have MNG working across all platforms) 

Comment 41

17 years ago
Adding dependancy on bug 36694.

German, if I've read you correctly, once PNG and MNG work on all platforms, a 
goal I hope Mozilla is trying to achieve before Mozilla 1.0, the only relevant 
difference between GIF and PNG would be that PNG has a better aura than GIF?

Then, assuming someone's willing to spend the time and effort into editing the 
.css files and creating PNGs which look good even in the web safe palette, and 
willing to make sure it keeps working, then what's to stop Mozilla from adopting 
that, then, as the new default skin? The incentive being that PNG has a better 
aura than GIF.

John Dobbins, in the mean time, would you be willing to create a 
Work-In-Progress ModernPNG theme and make that available for download (.tgz) or 
install (.xpi) somewhere? That way people can test it and give feedback on 
stability / usability.
Depends on: 36694

Comment 42

17 years ago
Other than bugs there is nothing fundamentally wrong with using PNG instead of 
GIF but for the in-house developed modern skin the risk to advantage ratio does 
not work to our benefit given the tight timeframe before releasing NSs beta 2. 
There will no visible end user benefit to putting PNGs onto the modern skin given 
the constraints for the modern skin (8-bit web safe etc) as outlined above.

Comment 43

17 years ago
Mmmhmmm, that's understandable. I didn't really expect this to be put in for 
nsbeta2, way too much other stuff needs doing.

So what about somewhere after nsbeta2, but before the release of Mozilla 1.0? 
Would the Target Milestone need updating?

Comment 44

17 years ago
Please submit this skin to mozillaZine's chrome zone so people can try it
out and help find any more bugs remaining in the png implementation. It will get wider distribution there
than it would if it were just left as an attachment to this bug.

Comment 45

17 years ago
Dawn I submitted it but Chris decided not to include it as a regular skin due to 
the Win transparancy problems. There is a news story about it though, 
currentally the top story. It has a link to download the file.

Comment 46

17 years ago
One look at will show that the Modern skin is in fact a 
Netscape skin. One look at Netscape 4.X will show that the Classic skin is also 
a Netscape skin. Since Netscape owns these skins it is entirely up to them what 
to do with thier skins. From what I've seen any work done on the Classic or the 
Modern skin is in effect working on a bug that has been resolved "Won't Fix".
I haven't given up on PNG based chrome though. Skin switching has been 
implemented. Right now the only choices are the Netscape skins. I think I'll 
follow johng's advice and branch. It's time Mozilla had it's own skin in 
addition to Netscape's skins. If Netcenter dosen't like the Mozilla skin then it 
can be left out of the Netscape builds.
I'm open to feedback. Should the focus of this bug be changed to developing a 
Mozilla skin? 

Comment 47

17 years ago
This bug is turning into a major project. UI engineering owns the skins 
currentally in Mozilla, and they are unwilling to make changes. The only way a 
PNG skin will be implemented is as a third skin. I am going to try to get 
approval for Mozilla to have it's own skin. As a first step I started a thread 
on N.P.M.UI. Comments are welcome. I have no idea how long this will take, so 
I'm setting the Milestone to future. This change does NOT mean I have stoped 
work on this bug. It mearly reflects that I am uncertain when this will be 
Target Milestone: M20 → Future
You guys should note that 8-bit alpha in PNGs is now working on Windows, except 
for Win98 which will be fixed shortly.

Comment 49

17 years ago
As far as I can tell, all *relevant* aspects of 18574 (MNG tracking bug) that
matter to chrome are fixed.  Things that still don't work are JNG support (at
least on a Win32 2000072008 build) and color correction, but neither matters for
chrome--at least not any more than their current lack in GIF-based chrome

So I recommend that bug 18574 be removed from the blocking list for this bug. 
(See my comment there for further details.)


Comment 50

17 years ago
Created attachment 12464 [details]
New PNG Skin

Comment 51

17 years ago
Attachment is a xpi. 
Skin tested on Win 98 and Redhat 6.2 with M18 branch nightlys.
MNG is not working on Win98 in chrome, so the 3 animated files are still GIFs. 
The MNGs are included in the skin. ( throbber.mng, loading.mng, and 
progressmeter.mng) all are in the global/skins directory.
All links to loading.gif/mng have been moved to point to the global/skin 
directory. I didn't test mng support on linux.
Still need tests on M17 branch for all platforms and Mac on M18 at the least.

Comment 52

17 years ago
MNGs not working in chrome is most likely due to bug 41333.

Comment 53

17 years ago
using PNG for the alert icons horks up the alert dialogs. The icon and any text 
are not displayed. For now I have returned these 4 Icons back to GIFs. To cut 
down on spam I have posted the updated version at, and will 
make minor updates avaible there. URL for updates added. Only major updates will 
be added here.

Comment 54

17 years ago
I vote for checkin this Neomodern into the tree.

Comment 55

17 years ago
Please ignore my last comment.

Comment 56

17 years ago
Had a look at the new Modern skin, and it's PNG!

And Thank you Netscape for letting me waste my time working on a feature you
were planning on implementing. It was real fun rereading the June 19th comments
from hangas and johng. Were you working on this then?

Reassigning to nobody. Anybody that wants to pick it up and mark it fixed after
Modern 2 finishes landing is welcome to it. I've put enough time in on this, and
won't even spend the time to mark it fixed.
Assignee: dobbinsj → nobody

Comment 57

17 years ago
Do you expect Netscape to plan 2 full months in the future? ;)

Be happy that they use PNG! You might have helped with that.

Comment 58

17 years ago
>Do you expect Netscape to plan 2 full months in the future? ;)

From N.P.M.UI thread "Should Mozilla have it's own skin"
Paul Hangas replied
>This is excellent!  I really want to see mozilla skins start coming to life.  
>The timing on this is perfect.  We are just now doing skin design work for 
>another Netscape 6 skin as well.

I found that after posting my last comment. Since I haven't seen any evidence of 
any other Netscape skins, I have to assume Modern2 is the skin mentioned on June 
If anyone at Netscape had bothered to inform me they were getting ready to 
implement a PNG based skin I would have reassigned this bug to them. Instead 
time I could have spent on other areas was wasted. At best my work was a 
testcase. I could have thrown a test case togather in an afternoon instead of 
trying to create a well crafted skin.

Comment 59

17 years ago
Created attachment 14376 [details]
NeoClassic xpi

Comment 60

17 years ago
So now it looks like Modern will stay GIF leaving Mozilla with no PNG based 
skin. Many of the problems Netscape had trying to implement a PNG based skin 
could have been avoided if Mozilla allready had a PNG based theme. Third party 
skin developers who wish to use PNG are also having problems.

The latest version of Neoclassic is attached. It is based on the classic theme 
and is in sync with it as of 20:00 PT last night. If this is checked in, the PNG 
bugs will be a lot easier to find, and there will be an easy way to reproduce 

Also PNG Transparancy is horked in Windows. bug 52088 has been filed.

Comment 61

17 years ago
Per the mozilla.ui thread, has anyone verified that, indeed, CSS colors are
*not* being gamma corrected?  (Simplest way to test:  create a PNG with some
mid-range colors, mark it sRGB--I think pngcrush will do that--and compare with
an HTML page with CSS colors on different platforms.)  If so, is there a bug
filed yet?  Sorry, I've been swamped with other things.

(The upshot is that, per the CSS spec, CSS colors should be gamma-corrected. 
And regardless of whether there's a preference for the user's display gamma,
the algorithm for doing the gamma correction must match what's used in the PNG

Btw, is Eli really the QA contact still?


17 years ago
Depends on: 53606


17 years ago
Depends on: 53597

Comment 62

17 years ago
Here's a test page (hope I did this right). I don't have a non-sRGB display to 
test it on, though. If Mozilla on Mac fails, a bug should be opened.

As mentioned earlier, one of the blocker bugs for fixing this bug is that we
hardcode the alert icons to be GIF. Is there a bug covering this exact issue?
Assignee: nobody → ben
Component: ImageLib → Skinability
QA Contact: elig → blakeross
Depends on: 59091

Comment 64

17 years ago
Pretriage of skinnability bugs, marking nsbeta1-, not going to get to this for 
Keywords: nsbeta1-
Jason, Hixie: Mozilla Win32 currently fails the test on the page Jason gave. We 
need to open a bug about that. I would, but I'd have no idea what to say.

Also, re: PNG/MNG in skins. AIUI, Modern2 is a PNG skin, but presumably uses 
animated GIFs for e.g. the throbber, because MNG in skins doesn't work. Is that 

CCing hewitt.

Hewitt: is there any chance the new modern could make this switch? At least to 
PNG, if not to MNG (as no-one seems to know if it works in chrome or not.)



16 years ago
QA Contact: blakeross → pmac
Mass move skinability bugs to, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted
Keywords: mozilla0.9.3
*** Bug 38638 has been marked as a duplicate of this bug. ***
Depends on: 121230


16 years ago
Depends on: 107225

Comment 69

15 years ago
Can we go ahead with this all the way now?  Is there anything else that could
cause an issue?  This should be a direct conversion-- no new features will be
used initially, which means alpha, gamma, etc. should have no bearing.


15 years ago
Blocks: 162764

Comment 70

15 years ago
Created attachment 104996 [details]
convert GIF to PNG/MNG; updates *.css and *.rdf files too

I made a bash script to convert skins from GIF to PNG and MNG.
Unzip, cd to the skin directory, run the script, zip the results.
Calls lots of utilities:
convert (from ImageMagick)
replace (mysql utility?)

Comment 71

15 years ago
Created attachment 107720 [details]
Classic theme for Mozilla 1.2 in PNG format


15 years ago
No longer depends on: 107225

Comment 72

14 years ago
This bug has been broken by a patch that checked in several
hours ago.


14 years ago

Comment 73

14 years ago
taking assignment.
Assignee: nobody → randeg


14 years ago
Blocks: 163993

Comment 74

14 years ago
Glenn: Do you plan on doing the PNG part of this (convert all still GIF
images to PNG format) before or after MNG comes back?
Summary: Chrome should use PNG instead of GIF... → Chrome should use PNG (and MNG) instead of GIF

Comment 75

14 years ago
Yes, one of those.  Note that the motivation for switching *everything* from
GIF disappears with the lapse of the LZW patent in the US in a few days.
So I will be concentrating on those where there are technical reasons for
switching such as ones that are transparent and should be antialiased (e.g.
the Firebird throbber), and ones that compress better as PNG than as GIF.
> Note that the motivation for switching *everything* from
> GIF disappears with the lapse of the LZW patent in the US in a few days.

<cough> Er, the patent is still valid in the UK and other countries for at least
another year. And, even after it's expired, a lot of hackers' copies of the Gimp
won't have GIF support. We should switch to PNG throughout to avoid patent
problems in any country, for consistency, for ease of modification, and because
of the message it sends.


Comment 77

14 years ago
I believe Moz only reads GIFs, and the theory all along has been that reading
isn't covered by the patent.  So as long as all GIFs were created in the US
after 20 June 2003 we should be OK.  I can as a part of this project recompress
them all so they get a timestamp after 20 June and a comment "Made in the USA"
or something to that effect.

Things are going to be rather complicated for freeware that makes GIFs during
the next year.  Unisys has said that they plan to enforce the patent wherever
it still is valid.

I agree with gerv about sending the right message, but why start now?  If we
really do want to start sending a better message, I'll be pleased to do the
all-GIF-to-PNG conversion.

Note that some of the work has been done already in the attachments to this
bug and to bug #38638
> So as long as all GIFs were created in the US after 20 June 2003 we should be 
> OK.

So only US citizens can contribute skin updates for the next year? Not very
"free software" :-| IMO, we should continue with the "all PNG/MNG" plan - when
we work out what's happening with MNG.


Comment 79

14 years ago
Not "US citizens" but anyone who has shell access to a computer in the US.
Or who write uncompressed GIFS and could ask someone here to recompress
their files, or they could use commmercial licensed software.  The last is
the only alternative for anyone right now; I hope all the GIFs in the tree
were compressed with licensed software.  I don't think there are any uncompressed
ones there.

Comment 80

14 years ago
Note, another motivation is the other feature that PNG brings with it: alpha
blending.  GIF files are restricted to only level of transparency.  While that's
not an issue for the current skin; it could become one for future revisions. 
Besides, with drop-in replacement PNGs, new skins could be a little quicker to
produce at least when mod'ing the default and standard skins, and
hopefully/possibly with some nice effects.  Imagine buttons with alpha blended
borders/highlights to give a soft dome feel over a textured background.  You can
have pseudo gloss with alpha blended masks and you don't have to worry about
placement over a particular backround if you wanted to use an image as the
shading/beveling could be an overlay.

Technically, there might not be much to gain.  Politically and from a legal
perspective, there's a lot of unnecessary baggage that can be shed by persuing this.

Comment 81

14 years ago
"and ones that compress better as PNG than as GIF."

This should be most of them. PNG's deflation has better average performance
than GIF's LZW, and deflation with Paeth filtering is much more powerful
than LZW without filtering.

This bug seems to cover conversion of the Classic and Modern theme
content from still GIF to PNG.  Shouldn't it be in component "themes"?
Or are there significant underlying theme engine bugs (other than
bug 18574 to put MNG back in) that preclude the switch?

(Removing dupe from depends.)
No longer depends on: 53606

Comment 82

14 years ago
Many of the GIF images in the tree are only a couple hundred bytes, where
PNG's 53-byte chunk header overhead overwhelms the better compression.
Throbbers, on the other hand, are larger files that compress much better
as MNG than as GIF.

A few days ago I put some comparisons of MNG versus GIF images of the
Classic/Modern throbber and the Firebird Throbber as attachments to
Bug #195280 (shortly I'll move the new throbber images over here). 
The latter is a nice example of how much better MNG looks; the GIF has
ugly white haloes when displayed against a dark background.

Comment 83

14 years ago
Created attachment 126016 [details]
modern/classic throbber in MNG format, 9867 bytes

Comment 84

14 years ago
Created attachment 126017 [details]
modern/classic throbber, 16x16, MNG format, 3149 bytes

Comment 85

14 years ago
Created attachment 126018 [details]
Original GIF and optimized MNG throbbers side by side

This throbber appears twice in the tree, under "modern" and "classic",
in 32x32 and 16x16 sizes both places.

Total size of GIFs: 65684 bytes.
Total size of MNGs: 26032 bytes.

Comment 86

14 years ago
Created attachment 126092 [details]
Firebird throbber in MNG format, 3985 bytes

Comment 87

14 years ago
Created attachment 126094 [details]
Firebird throbber and GIF side-by-side against black background

Firebird throbber, GIF: 8643 bytes
Firebird throbber, MNG: 3985 bytes

Comment 88

14 years ago
>Contra PNG:
>- Requires to start a converter which converts GIF -> PNG for each image =:-)

I'll convert all your GIF files to PNG/MNG in the chrome if you implement it.

Comment 89

14 years ago
I have a batch converter that converts GIF to PNG. I bet there is something
similar for MNG too. I will attach it so anyone who is interested can have a look.

Comment 90

14 years ago
Created attachment 129983 [details]
Conversion and optimization tools GIF -> PNG (RAR Archive, Part 1)


14 years ago
Attachment #129983 - Attachment description: Conversion and optimization tools GIF -> PNG (1) → Conversion and optimization tools GIF -> PNG (RAR Archive, Part 1)

Comment 91

14 years ago
Created attachment 129985 [details]
Conversion and optimization tools GIF -> PNG (RAR Archive, Part 2)

Comment 92

14 years ago
I believe the conversion could be quite easily done with ImageMagick, I doubt
another tool would be needed...

Comment 93

14 years ago
Perhaps now that MNG's gone, we should break off the MNG side of this into
a separate bug so that it no longer depends on 18574, which is unlikely to
get fixed soon.

Comment 94

14 years ago
That's OK with me, although a "chrome should use MNG" bug would probably get
immediately marked "invalid".  Go ahead and give it a try.  Since the "(and
MNG)" part of the summary of this bug is invalid now I'm removing it.
Summary: Chrome should use PNG (and MNG) instead of GIF → Chrome should use PNG instead of GIF

Comment 95

14 years ago
Which means we can remove the dependency on bug 18574 (restore MNG support).
No longer depends on: 18574

Comment 96

14 years ago
We should probably add an additional bug for conversion of animated gifs to MNG,
which then should be dependent on our beloved MNG resurrection bug.
Man I'd hope to see progress there...
Is this now dependent on bug 257197 (APNG)?

Comment 98

13 years ago
It depends on having some sort of PNG-based animation capability.  So it depends
on either 251197 or 18574 but not both.  Marking dependency on APNG for now.
Depends on: 257197

Comment 99

13 years ago
Other than the animated one, shouldn't the rest be PNG by now?  

Comment 100

13 years ago
Would it be best to morph this bug into a bug for still images and branch
throbber discussion to a separate bug?


12 years ago
No longer blocks: 163993

Comment 101

12 years ago
So, what's the status on this bug? Is it separate for toolkit and for XPFE? Is there some backend code involved? etc.

Comment 102

12 years ago
Eyal, it's a theme issue and actually separate for every theme. Of course, this makes it a separate matter for toolkit and xpfe as well, but what toolkit is used actually doesn't matter here. Not having any animated non-GIF format makes us all stuck with GIF throbbers though, for now.

Comment 103

12 years ago
Re Comment #100, changing the summary from
"Chrome should use PNG instead of GIF"
to "Chrome should use PNG instead of GIF for still images".
This might let us get to work on it instead of debating the issue.
Summary: Chrome should use PNG instead of GIF → Chrome should use PNG instead of GIF for still images
This is probably WONTFIX.  The patents have expired, and there are cases where GIFs are smaller.  I believe we used GIFs for SeaMonkey's autoscroll icons specifically because it was smaller than PNG in that case.

Comment 105

11 years ago
There are indeed cases where GIFs are smaller, but there is an opportunity to save some space by converting those where the PNGs are smaller.  I find 1322 GIFs on the trunk, in a Seamonkey checkout.  Of those about 38 are animated so forget them for now.  Of the rest, 1099 are smaller as GIF (each about 4 bytes smaller on average) and 185 are smaller as PNG (each about 800 bytes smaller on average).  A savings of 162 kbytes could be realized by converting the 185 that are smaller as PNG.
Ok, have an up-to-date patch against trunk?

Comment 107

11 years ago
I actually think changing the theme images right now is probably a waste of time. The new images we're using with bug 348720 are PNGs anyways (created from SVGs) and I don't think it makes much sense to convert the current old images when new ones are being created anyways.

Comment 108

11 years ago
(In reply to comment #106)
> Ok, have an up-to-date patch against trunk?

Nope.  Converting the images themselves isn't too big of a deal, but finding
all the references to them and fixing those, and finding the symbolic links
and fixing any references to those is hard to automate.  Also there are several
*.gif files that aren't really GIFs.  Would you be interested in a patch that
only replaces a few files, those that show the most savings when converted?
Does the image loader go on extension or on magic characters? If the latter, who says we need to rename the files? ;-) OK, it's a hack, but 165k of savings is not to be sneezed at. (Although I'd be interested in seeing figures of what that translates to in download size, after the overall compression is applied.)


Comment 110

11 years ago
On a related note, the image files in chrome that are already PNGs could be made much smaller.  Most of them have unnnecessary chunks, such as tEXT, pHYs, iCCP, gAMA, and cHRM (latter three could be removed by converting to sRGB and saving as an untagged file).

Comment 111

11 years ago
Removing unneeded chunks and compressing IDAT (pngcrush -rem alla) shrinks the current PNGs in toolkit and browser by 108K total uncompressed, 64K compressed.

Comment 112

11 years ago

Gerv: I think the image loader would do the right thing with a *.gif
that actually contains a png, but I'm not sure that would happen under
all usages.  Also, neither PNG nor GIF files are very compressible, so
the effect on download size is probably the same as the raw filesize

Here are the 10 most-improveable files.  The figure at the left is
the size reduction after converting to PNG and pngcrushing.  Improvement
would be 13 bytes less per file if an sRGB chunk were added.  I used
GraphicsMagick's "convert" to do the conversion.  Better compression
is achievable sometimes, by rearranging the palette.

4453 mozilla/layout/html/tests/block/images/tech-banner2.gif
4456 mozilla/themes/modern/editor/icons/btn2.gif
4967 mozilla/content/xml/tests/books/kerouac.gif
5141 mozilla/layout/html/tests/table/images/rock_gra.gif
5346 mozilla/layout/html/tests/block/images/tech-banner1.gif
7171 mozilla/themes/modern/navigator/icons/btn1.gif
8369 mozilla/layout/doc/SpaceManagerClasses.gif
14502 mozilla/themes/modern/messenger/icons/btn1.gif
16225 mozilla/themes/modern/editor/icons/btn1.gif
18502 mozilla/layout/html/tests/block/images/animated_gif.gif

Comment 113

11 years ago
(In reply to comment #109)
> Does the image loader go on extension or on magic characters? If the latter,
> who says we need to rename the files? ;-) OK, it's a hack, but 165k of savings
> is not to be sneezed at.

I would not like to see a bunch of *.gif that were really png, but how about this:
add file.png, and replace file.gif with a symbolic link to the new png?  It's still a hack, and wastes 8 bytes per file, but it's a little more evident to future gurus what's happened.  When they type "ls -l btn1.*" they see
  lrwxr-xr-x  1 glennrp  visitor     8 Jan 17 11:55 btn1.gif -> btn1.png
  -rw-r--r--  1 glennrp  visitor  9538 Jan 17 10:57 btn1.png

Comment 114

11 years ago
Not all platforms support symbolic links like that.
I think all of Glen's top 10 are not actually shipped in Firefox.

Glen: are you able to install Firefox, unzip the JARs in the chrome directory, do a "find -name "*.gif"" and see what you can do with those files?


Comment 116

11 years ago
Gerv:  I did a checkout of Firefox from CVS and found no JARs in the
chrome directory.  However, there are 577 plain GIF files in various directories.  Of those, 551 are good single-image files.  132 of those are smaller as PNG.  Here are the top 21 (all files that exhibit 1000 bytes or more savings when converted to PNG):

1005 ../mozilla/layout/html/tests/table/images/tbl-border-conflict.gif
1126 ../mozilla/xpfe/global/resources/content/logo.gif
1135 ../mozilla/layout/html/tests/table/images/bnr_all.gif
1213 ../mozilla/layout/html/tests/table/images/l_logo.gif
1220 ../mozilla/layout/html/tests/table/images/cnn.gif
1243 ../mozilla/layout/html/tests/block/images/vert_pixel_ruler.gif
1244 ../mozilla/layout/html/tests/table/images/next.gif
1249 ../mozilla/parser/htmlparser/tests/html/bg2.gif
1284 ../mozilla/layout/html/tests/block/images/mozilla-banner.gif
1284 ../mozilla/layout/html/tests/table/images/mozilla-banner.gif
1329 ../mozilla/layout/reftests/bugs/mozilla-banner.gif
1511 ../mozilla/layout/html/tests/table/images/smblue_paper.gif
1555 ../mozilla/layout/html/tests/table/images/edge.gif
2327 ../mozilla/layout/html/tests/attributes/mapimg87.gif
2562 ../mozilla/layout/html/tests/table/images/rclogo460.gif
3494 ../mozilla/layout/html/tests/mynet.gif
4419 ../mozilla/layout/html/tests/block/images/tech-banner2.gif
4429 ../mozilla/extensions/irc/xul/skin/images/blue_rock.gif
5107 ../mozilla/layout/html/tests/table/images/rock_gra.gif
5312 ../mozilla/layout/html/tests/block/images/tech-banner1.gif
8455 ../mozilla/layout/doc/SpaceManagerClasses.gif

Comment 117

11 years ago
Glenn -

What Gerv was saying is that even though they may be in CVS, they are not necessarily packaged and shipped.  If you have a Mozilla product installed, go to the application directory and look for .jar files in the chrome folder.  For example, you would want classic.jar from Firefox.

The files that you listed are often in the "tests" folder.  I don't believe that is shipped by default.


Comment 118

11 years ago
I have a particular 3rd party build of Firefox 2.0 for Windows.  It has a "classic.jar" that contains 42 GIF files.  None of those are smaller when converted to PNG.
OK. So it looks like there's not much gain to be had here in terms of improving the download size of Firefox. You could try with Thunderbird, Seamonkey etc. as well if you liked, but I suspect you'd get the same results.

Close as WONTFIX?


Comment 120

11 years ago
Seems to me PNG is on the whole more space efficient and it's better to just switch everything to it and have a uniform format rather than fiddle with which files compress better with GIF. Also, PNG allows 24-bit color which GIF doesn't. 

So I for one still think switching everything to PNG is a Good Thing.
But we're not talking about theoretical files, we are talking about the files we have. They don't need 24-bit colour, and PNG is not smaller. Or, to put it another way, *GIF* is smaller. So you are advocating switching from one format to another, the only effect of which would be to give someone some work to do, and increase the download size. I don't see that as a win.

There are no longer patent problems with GIF. If anyone can demonstrate a download size reduction for any Mozilla project application via converting from GIF to PNG (or vice versa, for that matter), please open a new, specific bug listing the files you want to convert and the size decrease expected.

Last Resolved: 18 years ago11 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.