Closed
Bug 8415
Opened 25 years ago
Closed 18 years ago
Chrome should use PNG instead of GIF for still images
Categories
(Core Graveyard :: Skinability, enhancement, P3)
Core Graveyard
Skinability
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: roland.mainz, Assigned: glennrp+bmo)
References
()
Details
(Keywords: helpwanted)
Attachments
(14 files)
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
video/x-mng
|
Details | |
(deleted),
video/x-mng
|
Details | |
(deleted),
video/x-mng
|
Details | |
(deleted),
video/x-mng
|
Details | |
(deleted),
video/x-mng
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details |
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
Assignee: don → pnunn
Status: ASSIGNED → NEW
Component: Apprunner → ImageLib
QA Contact: leger → elig
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
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 5•25 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 http://people.netscape.com/endico/sandbox/ spitzer
will be checking them in tonight.
Comment 7•25 years ago
|
||
adding dependency on bug 6323. jpeg and png images don't display on freebsd.
changing milestone to match 6323
Comment 8•25 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.
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
Comment 10•25 years ago
|
||
s/problem/problems/
-pn
Updated•25 years ago
|
Target Milestone: M9 → M10
Comment 11•25 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
bug.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → LATER
Comment 12•25 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.
http://www.mozillazine.org/chrome/gallery.html
Reporter | ||
Comment 13•25 years ago
|
||
;-((
What about the idea that Mozilla's nightly builds are shipped with multiple
chromes ?
What about a text-only chrome ?
Comment 14•25 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 verah@netscape.com to
get instructions on using it into the release notes?
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 15•25 years ago
|
||
Steve Morrison rocks! Verifying later.
Comment 16•24 years ago
|
||
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
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M10 → M20
Comment 17•24 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•24 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-
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.
Comment 19•24 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.
Comment 20•24 years ago
|
||
taking myself off the cc: list.
I'm interested, but I'm drowning in email.
-P
Comment 22•24 years ago
|
||
Comment 23•24 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
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.
Comment 24•24 years ago
|
||
Comment 25•24 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•24 years ago
|
||
Comment 27•24 years ago
|
||
Comment 28•24 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. :)
Reporter | ||
Comment 29•24 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•24 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•24 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•24 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?
Comment 33•24 years ago
|
||
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.
Comment 34•24 years ago
|
||
> 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
Reporter | ||
Comment 35•24 years ago
|
||
Well, no arguments any more - matty@box.net.au 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•24 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.
pete
Comment 37•24 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: mng
Comment 38•24 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•24 years ago
|
||
Someone should probably add bug 36694 as a blocker of this then, right?
Comment 40•24 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•24 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•24 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•24 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•24 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.
http://mozillazine.org/chromezone/ It will get wider distribution there
than it would if it were just left as an attachment to this bug.
Comment 45•24 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•24 years ago
|
||
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?
Comment 47•24 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
implemented.
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•24 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
matters.
So I recommend that bug 18574 be removed from the blocking list for this bug.
(See my comment there for further details.)
Greg
Comment 50•24 years ago
|
||
Comment 51•24 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•24 years ago
|
||
MNGs not working in chrome is most likely due to bug 41333.
Comment 53•24 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 http://x.themes.org, and will
make minor updates avaible there. URL for updates added. Only major updates will
be added here.
Comment 54•24 years ago
|
||
I vote for checkin this Neomodern into the tree.
Comment 55•24 years ago
|
||
Please ignore my last comment.
Comment 56•24 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
Status: ASSIGNED → NEW
Comment 57•24 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•24 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.
>
>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.
Comment 59•24 years ago
|
||
Comment 60•24 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
them.
Also PNG Transparancy is horked in Windows. bug 52088 has been filed.
Comment 61•24 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
code.)
Btw, is Eli really the QA contact still?
Comment 62•24 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.
http://home.mieweb.com/jason/testbed/srgb/
Comment 63•24 years ago
|
||
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?
Assignee: nobody → ben
Component: ImageLib → Skinability
QA Contact: elig → blakeross
Comment 64•24 years ago
|
||
Pretriage of skinnability bugs, marking nsbeta1-, not going to get to this for
beta1
Keywords: nsbeta1-
Comment 65•24 years ago
|
||
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
Comment 66•24 years ago
|
||
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
Comment 67•23 years ago
|
||
Mass move skinability bugs to nobody@mozilla.org, helpwanted.
Assignee: ben → nobody
Keywords: helpwanted
Updated•23 years ago
|
Keywords: mozilla0.9.3
Comment 68•23 years ago
|
||
*** Bug 38638 has been marked as a duplicate of this bug. ***
Comment 69•22 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.
Comment 70•22 years ago
|
||
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?)
Comment 71•22 years ago
|
||
Comment 72•21 years ago
|
||
This bug has been broken by a patch that pavlov@pavlov.com checked in several
hours ago.
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 73•21 years ago
|
||
taking assignment.
Assignee: nobody → randeg
Status: ASSIGNED → NEW
Comment 74•21 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
Assignee | ||
Comment 75•21 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.
Comment 76•21 years ago
|
||
> 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
Assignee | ||
Comment 77•21 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
Comment 78•21 years ago
|
||
> 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
Assignee | ||
Comment 79•21 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•21 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•21 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
Assignee | ||
Comment 82•21 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.
Assignee | ||
Comment 83•21 years ago
|
||
Assignee | ||
Comment 84•21 years ago
|
||
Assignee | ||
Comment 85•21 years ago
|
||
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.
Assignee | ||
Comment 86•21 years ago
|
||
Assignee | ||
Comment 87•21 years ago
|
||
Firebird throbber, GIF: 8643 bytes
Firebird throbber, MNG: 3985 bytes
Comment 88•21 years ago
|
||
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.
Comment 89•21 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•21 years ago
|
||
Updated•21 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•21 years ago
|
||
Comment 92•21 years ago
|
||
Vedran:
I believe the conversion could be quite easily done with ImageMagick, I doubt
another tool would be needed...
Comment 93•21 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.
Assignee | ||
Comment 94•21 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•21 years ago
|
||
Which means we can remove the dependency on bug 18574 (restore MNG support).
No longer depends on: mng
Comment 96•21 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...
Comment 97•20 years ago
|
||
Is this now dependent on bug 257197 (APNG)?
Assignee | ||
Comment 98•20 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: apng
Comment 99•20 years ago
|
||
Other than the animated one, shouldn't the rest be PNG by now?
Comment 100•20 years ago
|
||
Would it be best to morph this bug into a bug for still images and branch
throbber discussion to a separate bug?
Comment 101•19 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•19 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.
Assignee | ||
Comment 103•19 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.
Assignee | ||
Comment 105•18 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•18 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.
Assignee | ||
Comment 108•18 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?
Comment 109•18 years ago
|
||
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
Comment 110•18 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•18 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.
Assignee | ||
Comment 112•18 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
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
Assignee | ||
Comment 113•18 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•18 years ago
|
||
Not all platforms support symbolic links like that.
Comment 115•18 years ago
|
||
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
Assignee | ||
Comment 116•18 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•18 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.
-Alan
Assignee | ||
Comment 118•18 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.
Comment 119•18 years ago
|
||
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
Comment 120•18 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.
Comment 121•18 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 25 years ago → 18 years ago
Resolution: --- → WONTFIX
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•