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
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
Let's get the browser robust first. priorities -pn
Updating QA Contact
reopening and moving to dawn, since she's actually tested this. -pn
Dawn. 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. -P
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 http://people.netscape.com/endico/sandbox/ spitzer will be checking them in tonight.
adding dependency on bug 6323. jpeg and png images don't display on freebsd. changing milestone to match 6323
how we comin' on this. at this point if its not ready we should most likely try and get in during early M10.
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.... -pn
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 bug.
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. http://www.mozillazine.org/chrome/gallery.html
;-(( What about the idea that Mozilla's nightly builds are shipped with multiple chromes ? What about a text-only chrome ?
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 firstname.lastname@example.org to get instructions on using it into the release notes?
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? Gerv
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.
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- busy.gif 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 Chromezone.
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.
taking myself off the cc: list. I'm interested, but I'm drowning in email. -P
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 Branch. 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.
Looks pretty good on WinNT 4 sp6a. Well, let me rephrase that. It looks as good as can be expected without transparency.
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. :)
BTW: Does Mozilla 5 ship with a B/W-skin per default (one-bit deep !!) or should I file a RFE for this ?
On MacOS9 using MN16 final the package looks as good as can be expected and I haven't found any problems.
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.
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
Well, no arguments any more - email@example.com 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 =:-)
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. pete
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.
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.
Someone should probably add bug 36694 as a blocker of this then, right?
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)
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.
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.
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?
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. http://mozillazine.org/chromezone/ It will get wider distribution there than it would if it were just left as an attachment to this bug.
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.
One look at http://home.netscape.com 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?
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 implemented.
You guys should note that 8-bit alpha in PNGs is now working on Windows, except for Win98 which will be fixed shortly.
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 matters. So I recommend that bug 18574 be removed from the blocking list for this bug. (See my comment there for further details.) Greg
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.
MNGs not working in chrome is most likely due to bug 41333.
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 http://x.themes.org, and will make minor updates avaible there. URL for updates added. Only major updates will be added here.
I vote for checkin this Neomodern into the tree.
Please ignore my last comment.
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.
Do you expect Netscape to plan 2 full months in the future? ;) Be happy that they use PNG! You might have helped with that.
>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. > >paul 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 22. 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.
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 them. Also PNG Transparancy is horked in Windows. bug 52088 has been filed.
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 code.) Btw, is Eli really the QA contact still?
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. http://home.mieweb.com/jason/testbed/srgb/
triaging... 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?
Pretriage of skinnability bugs, marking nsbeta1-, not going to get to this for beta1
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 right? Gerv
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.) Gerv
Mass move skinability bugs to firstname.lastname@example.org, helpwanted.
*** Bug 38638 has been marked as a duplicate of this bug. ***
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.
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) gif2png pngrewrite pngcrush replace (mysql utility?)
This bug has been broken by a patch that email@example.com checked in several hours 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?
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. Gerv
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. Gerv
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.
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.
"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.)
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.
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.
Created attachment 126094 [details] Firebird throbber and GIF side-by-side against black background Firebird throbber, GIF: 8643 bytes Firebird throbber, MNG: 3985 bytes
QUOTE: >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.
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.
Created attachment 129983 [details] Conversion and optimization tools GIF -> PNG (RAR Archive, Part 1)
Created attachment 129985 [details] Conversion and optimization tools GIF -> PNG (RAR Archive, Part 2)
Vedran: I believe the conversion could be quite easily done with ImageMagick, I doubt another tool would be needed...
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.
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.
Which means we can remove the dependency on bug 18574 (restore MNG support).
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)?
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.
Other than the animated one, shouldn't the rest be PNG by now?
Would it be best to morph this bug into a bug for still images and branch throbber discussion to a separate bug?
So, what's the status on this bug? Is it separate for toolkit and for XPFE? Is there some backend code involved? etc.
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.
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.
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.
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?
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.
(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.) Gerv
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).
Removing unneeded chunks and compressing IDAT (pngcrush -rem alla) shrinks the current PNGs in toolkit and browser by 108K total uncompressed, 64K compressed.
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 differences. 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
(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
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? Gerv
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
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. -Alan
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? Gerv
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. Gerv