Closed Bug 195280 Opened 22 years ago Closed 22 years ago

Removal of MNG/JNG support

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tor, Assigned: tor)

Details

Attachments

(5 files, 3 obsolete files)

mng removal patch
52.48 KB, patch
pavlov
: review+
blizzard
: superreview+
dbaron
: approval1.4-
Details | Diff | Splinter Review
Mozilla Browser (firebird) default theme throbber
23.86 KB, video/x-mng
Details
Screenshot of broken behavior (GIF/LZW format)
9.70 KB, image/gif
Details
Comparison of MNG and GIF throbbers against white and black background
49.44 KB, image/png
Details
Comparison of 256-color and 16-color modern throbbers
38.89 KB, image/png
Details
While these formats have some interesting features, I think it's worth considering removal of this decoder from the mozilla tree. Some of the reasons: * mng decoder module is roughly the same size as all the other image decoders and libpr0n logic combined. Linux sizes: 261796 libimglib2.so 241492 libimgmng.so MS-Windows sizes: 155024 imglib2.dll 170336 imgmng.dll * mozilla integration is rather rough, partly due to a necko bug (possibly fixed by darin's recent async changes) and partly due to the lack of active, interested maintainers. * animated gifs and flash (and possibly svg in the future) cover much of the feature set of mng. jng is a bit more interesting, but not in ways that most people will care about. * the formats are little used in the wild. * the formats are not w3c recommended.
Please, no. Personally, I'm just starting to use JNG. MNG is apparently popular in Asia. It's in, it works, let's leave it in.
Why not just disable by default, instead of removing? we have a configure option for the image decoders these days.
Nice timing, only 3-1/2 months before we could unveil MNG-LZW. Glenn
Note that bug 48893 suggests using libmng to handle PNGs as well as MNGs, which would remove some code and not lose any format support.
I can only say that I'd regret it if this decision goes through. I know I'm rather partial since it's pretty much like flushing three years of my life down the drain, but if it's for the greater good of the project I can't really stop you. I do know that MNG is pretty popular in the far-east, so I hope there will be a fair assessment as to the 'low-spreadedness', if that's the main motive. From a developer's pov I also think it's not a good marketing idea to remove support for a feature that's been around for a while, even if it's use is limited (at the moment). AS to development, I'll be releasing 1.0.5 final this weekend. It's a bit bigger again as I've added near 100% support for all MNG features, so size-wise I'm not doing myself any favors I suppose. But I do believe the new dynamic MNG feature could be a very nice bonus, as it will allow quick rollover buttons and maps (hover/click; w or w/o masks) inside just a single small image-file. Gerard
Glenn: Care to explain what MNG-LZW is? Gerard: I'll be a bit sad to see it go as well, since it was what started me actually writting mozilla code instead of just doing SUNWspro portability patches. The top four in that list of reasons have about equal weighting in my view. The last was just tacked on for completeness. The size isn't that surprising, given that MNG/JNG essentially have all the features of the other image formats. The fact that we're statically linking libjpeg into both imglib2 and imgmng isn't helping matters.
>The fact that we're > statically linking libjpeg into both imglib2 and imgmng isn't > helping matters. Well, if imgmng were part of imglib2, quite some space would be saved, no? how large is the jpeg library?
>The fact that we're > statically linking libjpeg into both imglib2 and imgmng isn't > helping matters. JPEG functions aren't exported from the imglib2.so/.dll? Is zlib statically linked as well? > Well, if imgmng were part of imglib2, quite some space would be saved, no? > how large is the jpeg library? Around 25% in my personal implementation if including zlib; 29% otherwise. > * mozilla integration is rather rough, partly due to a necko bug > (possibly fixed by darin's recent async changes) and partly > due to the lack of active, interested maintainers. If changes in the libmng API can aid in this process, please let me know. And I'd volunteer for this position if I'd have an idea what to do. > * animated gifs and flash (and possibly svg in the future) cover > much of the feature set of mng. jng is a bit more interesting, > but not in ways that most people will care about. Sure there are duplicates, but there are a lot of techniques/standards on the web that pretty much do the same thing, just in a slightly different way. It's a matter of choice. You wouldn't like to be forced to use MS Windows, would you? You'd like to have a choice, right? > * the formats are not w3c recommended. That's something the PNG group is currently working on. W3C are too engrossed in their own svg format, so have already let us know they're not interested. On another note, I've had promising talks with MS, and IE (perhaps even Windows itself) may have MNG support in the not too distant future. Gerard
> Glenn: > > Care to explain what MNG-LZW is? A joke: MNG in which LZW compression is used instead of zlib in the embedded PNG files. Not as effective but maybe faster. #:-) Where's the "Vote against this bug" button? Glenn
I must say ive seen both (mng vs gif) and mng is way better graphicly. I already plan on making a lot of mng based projects with blender 3d editor. I came here with a bug to report about mng which is directly typing in mng url will display the mng file as a text file instead of displaying a picture. I must vote against the idea to remove this format support expecially since this format is gaining a lot of support and can only expect it to really get big as soon as good animation software is made.
Its a pity, as i am just checking out image file formats for my site, and JNG actually seems about the best feature set. It seems well supported by ImageMagick . Mozilla seems to have the best PNG support, so it would be great for MNG/JNG support as well. Bring it back in 1.3.1!
Upgrading to libmng 1.0.5 caused the MNG decoder to grow by 33424 bytes on linux and by 25056 bytes on win32.
> Upgrading to libmng 1.0.5 caused the MNG decoder to grow by 33424 bytes on > linux and by 25056 bytes on win32. That's because it's now a full MNG decoder (not a subset), the first one ever. This is a Good Thing. I assume there must be a meta-bug somewhere driving the push for smaller code. If folks are really that worked up about distribution size--and let's be serious here, Mozilla and Netscape have been bloatware since the 2.x days--then I'd suggest starting with the newsreader and mail client. I don't know how much even one extra theme adds, but I wouldn't be surprised if it's a fair fraction of 100 KB... In the meantime, why not fix the code-duplication problems first, at least to the extent of using one (1) copy of libjpeg and one (1) copy of zlib. That should be a reasonably straightforward makefile fix. Later on, libpng could be removed, but that will require some recoding in order to switch to libmng's API. Greg P.S. Yes, I also vote to keep MNG/JNG support. Delta-MNG capability will be critical when I get around to converting my months and months of captured weather-radar images to MNG animations, and I've been coming up with more and more other MNG ideas. It would be a shame if I were the only one who could ever see them...
>Bring it back in 1.3.1! What are you talking about. Mozilla 1.3 will contain the MNG Decoder. Nothing is removed yet. This is still being discussed.
> In the meantime, why not fix the code-duplication problems first, at least to > the extent of using one (1) copy of libjpeg and one (1) copy of zlib. There is only one compiled copy of zlib in the mozilla distribution (ignoring the installer).
Libpng can be made smaller by use of the PNG_NO_*_SUPPORTED macros. In particular, PNG_NO_WRITE_SUPPORTED seems appropriate for the builtin libpng used with Moz. If you try this and do achieve some savings (I'm not sure it will because the linker should discover that the write functions are unused), please allocate those savings to preserving libmng. Glenn
> If folks are really that worked up about distribution size--and > let's be serious here, Mozilla and Netscape have been bloatware > since the 2.x days--then I'd suggest starting with the newsreader > and mail client. Thanks for your insult of many people's hard work. In addition to delivering an application suite and development platform, one of the goals of mozilla.org is to provide a gecko layout component that can be embedded to construct browsers or other applications. One such browser, Chimera/Camino, already appears to ship without mng (bug 188116, bug 188376), and Phoenix would probably remove it as well if they realized they were dragging around a couple hundred KBytes extra. > Libpng can be made smaller by use of the PNG_NO_*_SUPPORTED macros. > In particular, PNG_NO_WRITE_SUPPORTED seems appropriate for the > builtin libpng used with Moz. The linker is indeed stripping those functions, at least on Linux.
> Libpng can be made smaller by use of the PNG_NO_*_SUPPORTED macros. > In particular, PNG_NO_WRITE_SUPPORTED seems appropriate for the > builtin libpng used with Moz. I played around with removing those routines from PNG... however venkman has a dependency on them (for some reason) and so unless someone updates venkman, you can't remove them from the png libs. And tor is right at least on linux removing it doesn't save you much in terms of size.
Current size comparisons (from the 3/9 nightlies): Linux sizes: 269248 libimglib2.so 287580 libimgmng.so Win32 sizes: 155552 imglib2.dll 196160 imgmng.dll
I'm all for removing this along with some of the other rarely used decoders
> I played around with removing those routines from PNG... however > venkman has a dependency on them (for some reason) and so unless > someone updates venkman, you can't remove them from the png libs. I'm not quite sure what to make of that. Venkman is JavaScript and XUL, it doesn't depend on specifics of the PNG api. The only part of Venkman that isn't in js/xul is located in the js/jsd directory, and is strictly an interface to the js engine, with no dependencies on a graphics library.
If IE starts supporting this, we'd just have to add it straight back in again... Can we try some of the suggested size reduction fixes (dynamically linking with libjpeg/libimg2 for those functions, PNG_NO_WRITE_SUPPORTED and friends, and removing/making optional libpng) and see how far that gets us? Gerv
Results from some experiments on linux (optimized builds): Current tree: 280 -rwxrwxr-x 1 tor tor 280618 Mar 14 19:54 libimglib2.so* 300 -rwxrwxr-x 1 tor tor 301969 Mar 14 19:54 libimgmng.so* Including the MNG decoder into imglib2 - this will be approximately the same savings as dynamically linking libjpeg: 508 -rwxrwxr-x 1 tor tor 512812 Mar 14 20:41 libimglib2.so* Including the MNG decoder into imglib2 and removing libpng (MNG is a superset of PNG): 416 -rwxrwxr-x 1 tor tor 418444 Mar 14 20:56 libimglib2.so*
tor: Thanks for the info! if I do some rough math I get the following: libpng ±95KB libjpeg ±70KB libmng ±230KB So the savings for dropping MNG/JNG support against the integration are ±135KB. I'd have to make a few alterations in libmng (bug 48893) which would increase size, but I've also got a couple of ideas for decreasing the size (eg. disabling unused canvas-styles; disabling support for non-visual chunks). I'm thinking overal it would shrink a bit with this. But I'd hate to make an effort and it get's dropped anyway. How is this thing going to be decided? Democratic vote or just 1 person (or small group) decides? So far I count 7 votes against removing, 2 in favor of removing and 1 uncertain (although I've got a feeling Christian is also in favor of keeping it).
In general we have a good bit of standards support for things that aren't commonly used on the web but that we'd like to see become more common. (How common was PNG when we started supporting it?) Removing this seems to diverge from the attitude we've had in other areas (DOM, CSS) where we often support new standards when we think they're implementable and good for the web, even if they're not widely used yet. Removing this entirely seems a bit odd. If some people really don't want it, should it be a build option (as, say, xmlextras and transformiix are)? Or should we even let them refuse it?
Gerard: Yes. I would prefer keeping it in the tree. ~160 KB does not seem to much to me. People who do not want it can disable it at compile time with the --enable-image-decoders option.
So, we save 160K by including libmng in libimg (Tor's third option.) That sounds like it's worth taking for starters. This makes the extra footprint of taking libmng 135K. Then, why don't we give Gerard a chance to reduce his footprint somewhat? It's obvious that he sees the problem and is trying to do something about it. I also agree with dbaron's comment 26. Gerv
I'd strongly urge against option three - libpng has much more testing in the field than libmng, especially since Gerard is planning on making changes to make png decoding more efficient. I don't think the comparison with PNG is fair - PNG was supported before the public mozilla project started. It also filled a couple imaging niches - lossless 24-bit compression and alpha channel support. MNG's niches are much more narrow/nonexistent - 24-bit/alpha animation (which can be done with Flash) and JPEG with alpha channel.
I have only a passing interest in MNG - I don't use it, have never seen it in the wild, but nevertheless would be interested in a free image animation format (unlike GIF for example) that is natively supported (unlike the proprietary flash). How about the following option: * Make mng/jng support into a mozdev project installable by xpi. Replace mng/jng images by alt text telling the user where to download the xpi (even with a direct link to the xpi). This would mean that development of the decoder could continue, and could get smaller, whilst getting testing from those who use the format to ensure it is robust. When: (testing has been sufficiently approved | MNG becomes more popular | IE introduces MNG support ) & it has been worked out how to safely and efficiently blend the various decoders without repetition, then the decoder could be checked back into the trunk.
From a footprint perspective, I don't think having the MNG dll is really a huge deal, this really only affects download and installed footprint. MNG is only loaded when the DLL is loaded into memory. The place where we really care about footprint (embedding) doesn't include MNG support anyway. all the hubub about footprint is really about reducing duplicated code from the embedded product, finding more efficient ways of storing data, and so forth. Removing MNG support doesn't buy us much in my opinion. That said, why don't we make it an extension, built in mozilla/extensions?
Comment on attachment 117320 [details] [diff] [review] mng removal patch r=pavlov
Attachment #117320 - Flags: review+
> MNG's niches are much more narrow/nonexistent - 24-bit/alpha > animation (which can be done with Flash) Any sort of animation in an unencumbered and cross-platform format, in fact. If alecf (embedding guru) doesn't think it's really a footprint issue, and if it can be turned off by anyone who wants to using --enable-image-decoders, then what's wrong with the status quo (or any improvements we can make on it by eliminating duplicate copies of libjpeg)? Gerv
Just to add my two cents: I use MNG's in the NautiPolis theme, for nice anti-aliased alpha-transparent 24bit color animated 'images', such as the blinking leds in the tabs. Besided the animated gif, with only 8bit colors, and 1bit transparency, there is nothing else for smooth animation. I would say therefor, keep MNG in, and make a build pref for these people who really want to remove it. But, again, keep it in the fullblown Mozilla. Mozilla is THE testground for new web technologies, including MNG (or JNG or whatever).
Comment on attachment 117320 [details] [diff] [review] mng removal patch r=cls on the build changes. It's inspector, not venkman, which has the dependency upon libpng. No, I don't know why. While I disgree with the general notion of advocating a proprietary solution over an open one (re 24-bit alpha animation), if tor's stepping down as the mng maintainer and thinks the code should be removed, then it probably should be removed unless someone else is going to step up and maintain it. Not everything has to be part of the default mozilla tree. However, we do have a (questionable) precedent set by finger & gopher of moving unmaintained but marginally useful code into extensions/ .
>* Make mng/jng support into a mozdev project installable by xpi should it really be removed, I already said I'd make an XPI for it. >and make a build pref for these people who >really want to remove it. that exists already.
If it's a question of finding a maintainer for MNG, then we should try and do that. Is the QT port is a precedent? We tried to find a maintainer for a bit, failed, and it got removed. Here, we seem to be doing the removal before looking for the maintainer. As far as I can see, there's at least one obvious person. Gerard: how does the idea strike you? :-) Gerv
Gerv: not entirely crazy. I've been thinking about that too. I'm just not familiar with moz internals, and have yet to set up a dev environment and get familiar with it first. Not sure either whether to pick M$ or Linux or both. My middle-name is Delphi/Kylix, not MSVC or gcc. Also time could be a limiting factor, as I may be moving into a new job, and I'm not sure what kind of time consumption maintaining this baby brings with it.
I would vote for KEEPING MNG and JNG support as one of the main reasons I use PNG is JPEG doesn't support transparency and I'm using transparent images with more colors than GIF will support and I don't want dithering. If JNG would compress to a smaller image size than PNG and maintain the benefits of JPEG, I would switch in a heartbeat. I have nothing against PNG except for the image sizes. Peace....
Attachment #117320 - Flags: superreview?(blizzard)
Comment on attachment 117320 [details] [diff] [review] mng removal patch sr=blizzard I'm sad to see it go, but if it's not widely used and unmaintained, it probably shouldn't be in the tree.
Attachment #117320 - Flags: superreview?(blizzard) → superreview+
There are more than enough suggestions on alternatives to removal in this bug's comments.
Gerard indicated to me in private mail that he might be willing to maintain MNG. Gerard: are you going to step up to the plate? :-) Gerv
Gerv and all, I, more than anyone here, will be hurt when support for MNG gets dropped, since its really the only advertising tool available to promote a great non-proprietary non-patented animation format. Even if most of its functions are covered by other formats, its the only real choice for open-source minded people. I did mention that I'd be willing to maintain this thing, and I've also mentioned that I was willing to do some work on optimization. But as I'm starting a new job today and will be spending most of this month and part of june in the UK, I'm still willing but just not ready yet. Gerard
I've requested that someone who is empowered to do so reopen bug #18574 (the "MNG tracking bug") and suggest that votes for 18574 be considered to be votes against this proposal. Glenn
MNG will not be removed, for the same reason that marquee and blinking text will not be removed. There is a functional benefit to some to include it, and the cross benefit of removing the features would be completely negligible in today's age of 40+GB hard drives and 650MB CD-ROMs. The idea that support for an entire file format should be removed is absurd. I suggest WONTFIX or INVALID.
As for the W3C issue, bug 204288 has been created to evangelize W3C to support MNG.
The argument that Flash can do what MNG can do is a fallacy. Flash cannot be used as a background image, and as I understand it, plug-ins in general cannot have any transparency, let alone eight bits of it. Web developers use animated GIFs a lot, and would, if IE supported it, benefit from the 8bit alpha channel in MNG, which is my main reason for supporting MNG. Our supporting it may also help convince Microsoft to add support (it wouldn't be the first time). I agree that the MNG library seems remarkably bloated, but that is a bug that should be fixed, not a reason for us to take a step backwards.
I wouldn't be surprised if the popularity of MNG and JNG would increase once there are more painting tools supporting these formats. As a GIMP developer, I saw many requests for supporting these formats in the GIMP. Many reasons were cited for requesting the ability to work with MNG and JNG files, and Mozilla was one of them. A GIMP bug report about this has been submitted last year: http://bugzilla.gnome.org/show_bug.cgi?id=79131 One month ago, a new MNG plug-in was added in CVS. It is now available in the developer's release 1.3.14. It will be part of the next stable relase GIMP 1.4. It would be a pity to remove these formats from Mozilla when some tools are only starting to support them.
I wouldn't use the argument that Flash doesn't work as an animated background... that's a feature, not a bug. ;) All the same, however, disk space isn't a major issue. Heck, the size of the libmng file is smaller than a typical MNG animation! I would instead look at its performance, particularly how much processing power it uses in idle and active states. I assume since it's been in this long that there hasn't been any significant problem with CPU. Memory is also not an issue because a typical PC contains 256MB or more, not counting the pagefile. And of course, alpha transparency is a very powerful feature. Already I have seen a few sites that use PNG alpha transparency to create boxes of text with the background shining through. Of course the effect is lost in IE and Netscape (4) because they dispose of the alpha channel. (Also, that's two more for WONTFIX?)
Is there a "Removal of GIF support" bug?
I agree with Hixie, Gerv, and Dbaron. In any case, that patch isn't complete afaict. It doesn't remove Windows preferences.
It seems noone really wants to lose MNG support, and we have someone who knows MNG pretty well and wants to maintain it. Hmm, I also believe we'll get bashed and trolled if we remove it... So why the heck do it then?
As far as I can see, the disk footprint savings have no importance what so ever. A few hundred kilobytes lying on your hard drive does not worry anyone anymore, apart from the embedded folks but these people have already stated that they don't build these decoders anyway. Now, what about the download size savings? Well, if we really care about download size why haven't we simply recompressed the builds with bzip2 like people have been proposing before? The savings would be far better than the image decoding removal that this bug proposes, and *nothing* would be lost: 12569619 mozilla-i686-pc-linux-gnu.tar.gz 11309687 mozilla-i686-pc-linux-gnu.tar.bz2 The only valid argument for removing these decoders that I have seen in this bug is that the current maintainer does not want to maintain them anymore. That's understandable, but lets wait a little while for someone else to step up.
I've recommended in bug 18574 that it become a meta bug for the various issues with MNG and JNG support that tor complained about. I've filed bug 204520 for the size issue and bug 204288 for W3C support. Just because the person who wrote the patch to get MNG working doesn't want to work on Mozilla anymore doesn't mean MNG should be completely removed. That's ridiculous. If nobody objects or beats me to it, I'll resolve this to WONTFIX per the overwhelming consensus of the comments.
I have to disagree. It seems there is a concensus here, but please leave it up to the bug and component owner to resolve the bug. It would be considered unfriendly if you close it, I believe - and that wouldn't help us here...
Right, well whatever... but I will add a note that staff@mozilla.org must approve of any change to the image library that would result in a loss of file formats. It would be even more unfriendly to sneak in a patch that breaks MNG/JNG functionality.
Whiteboard: staff@mozilla.org support required for checkins to this bug
Skewer: thats one of the funniest bugzilla postings i've ever seen. The person who wrote this patch, tor, is the MNG decoder owner, and the person who reviewed it, me, is the imagelib owner. I suppose drivers, not staff, could step in here if they wanted to, but since it was already run past them, I think you're out of luck.
Whiteboard: staff@mozilla.org support required for checkins to this bug
Skewer's amusing intervention aside, Gerard has said he's willing to take a stab at whatever maintenance work MNG needs next month. Is that not good enough? I don't think anyone denies that there are optimisations outlined in this bug which should be made to avoid MNG taking more space than all the other image decoders combined (which I agree is a bit silly.) But by the time 1.5 alpha opens, Gerard should hopefully be available to do that work. Gerv
There is no reason to hold off removing it. If and when Gerard has time to step up and maintain it, he can put it on mozdev and release it as an addon. Recent google searches turned up 12 .jng files, 292 .mng files, 7.1 million .png files, 522 million .gif files. Given these numbers, I can see is no reason what-so-ever to continue supporting this format.
Before we added support for the more advanced CSS features, nobody used them either, except in test cases. When we added support, people started using them. That's how the Web works. Do you think people used PNGs before PNG support was in several browsers? of course not. Why is MNG any different? Before removing MNG, please tell me how else I can achieve 8bit alpha-channel animation in Mozilla, because I don't see any other way of doing it. (Just out of interest, how were the Google searches done?)
I agree with Hixie. It seams silly of us Mozilla supporters, with a maximum 2% of the market (all gecko browsers together) to discontinue support for an up-and-coming image format on the grounds that it is little used now. Also, we have first-hand support from the image format creator himself.
Re comment 57: > I suppose drivers, not staff, could step in here > if they wanted to, but since it was already run past them, I think you're out of > luck. Email was sent to drivers, and some members of drivers are opposed to the removal. (I don't think there was an "official" reply yet, but I can't find the thread right now, though.)
Re comment 57: I think that most of the posters here know that we have no power over this. With a fully qualified patch sitting there this bug could be resolved fixed at any time--Mozilla is not a democracy. What recourse do we have? Someone could close this bug WONTFIX, but that would just piss people off. We could sit down and start learning the internals of libmng and writing code to decrease the bloat, but more capable minds have already offered. We can vote for bug 18574 (which I have done), but that is liable to do about zilch. We can bitch and moan and beg and plead in comments (which I am doing here), but that is liable to have little effect and zero of it is likely to be positive. Someone could submit an article to MozillaZine, or to SlashDot forcasting doom and gloom, but that has never been productive. A maintainer was asked for, and one was found. Size reduction was an implied want, and they have been offered. I can think of reasonable reasons for this issue to be treated like this, but none have been offered up. And here I am breaking my rule of never post anything before noon, and that can't be good.
Duplicating a comment I posted over in bug #18574: I will work within libmng to look for ways of reducing its footprint. Glenn
pavlov@pavlov.net only removed the staff@mozilla.org requirement because he thinks he cannot get its support, I suspect. Why would anyone support a blatant regression to save a couple measly kilobytes?
A patch to this bug would also break the progress in bug 8415.
Skewer, you are in no position of authority to force such requirements on Mozilla contributors. AFAIK, only staff and/or drivers can impose such restrictions. It is clear that there is a debate and hopefully drivers will step in. The fact that they are aware of the issue should be enough for the time being. Let's maintain some integrity please and rather than spout accusations at people, it would better further your cause to continue offering solutions and/or benefits to keeping MNG in the tree. If you have nothing to add to the bug in addition to what you already have, then please don't subtract anything from it.
Attachment #117320 - Flags: approval1.4?
Removing MNG support will break Mozilla Browser (Firebird), as the default theme includes a mng throbber.
Here is another reason why MNG is important to Mozilla : http://www.allhtml.com/forum/index.php?t=l&f=1&i=262430 (in French) This is a forum thread posted yesterday were a computer-sciences student is asking for help with MNG support. His teachers forbid the use of the GIF format in the assignments they give to their classes because of the potential patent problems, as a result, all these future computer engineers have to install (and discover !) a Gecko browser for their studies. Suppress MNG support and these students will keep on using IE.
This bug confuses me. Why removing a free, open format and force people to use properietary formats instead? Why breaking the default theme of Mozilla Firebird? Because of 160K? This goes completely against my view of Mozilla.org supporting free, open standards in favor of proprietary formats. If there are ways to optimize the code, why not investigate in that instead of removing it? The only arguments I've seen from the owner (tor) is size and performance/bugs. That shouldn't be a reason to drop support for it alltogether, should it? It's like saying Winamp shouldn't support the open Ogg/Vorbis format just because the proprietary MP3 format is more common.
I suggest that before this patch is applied a few issues are resolved and answered. 1) Ligitimate pros and cons need to be acknowledged. A few of the current maintainers' main objectives of the patch were proven to be fallacies. (Flash & GIF are not liable alternatives) 2) A respectable PNG/MNG coder is willing to help mainain the code and this would break all his work getting mng support into mozilla . "...it's pretty much like flushing three years of my life down the drain.." 3) Size and performace issues need to be clarified. If these issues can be clarified, by all means the patch should be applied. We need a clear objective to be sought and explained before we send Moz/FB into any regressions.
As promised, I've done some work on reducing the libmng footprint. See today's comment from me in bug # 204520. Glenn
Patch checked in. libmng removed from the tree.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Just fyi, New throbbers were provided to the firebird/thunderbird teams and should be getting checked in soon.
I'm another theme author using MNGs in a few places (http://www.kmgerich/pinstripe/pinstripe.html). I'm sad to see this go because there is no alternative in Mozilla currently.
So just to clarify, 1.4 will ship with mng support, correct?
Yes. This was landed on the trunk and will not effect 1.4 at all.
Things like this are pissing me off more and more. Interesting features and ports get removed with strange reasoning, and noone's trying to get any compromise or something. (see also: qt port, toolbar grippies, etc.) A few more of those and I'll start proting MSIE to Linux just to get rid of Mozilla. Thanks. (And yes, it's intended to spam you with that message.)
what do you want to affect with this? If you want to make the libimgmng footprint smaler, help on that, but don't drop one key-feature after another! This is just totally idiotic. Do you want to scare of the last web deveoplers who like gecko or what?
Re comment #77: Ok, it's not yet removed from the 1.4 branch, but looking at the patch's flags you asked for approval to do so. Is this by intention and could Mozilla 1.4 still be affected after all?
So, the next optimalization will be the removal of both ICO and BMP files? Both aren't a W3C recommendation, and after all it will cost some disk/memory space to support them. We will also remove PNG-alpha transparency because IE doesn't support this and finally we will remove the CSS features that aren't supported in IE??? We will only have to wait for a bug to ask for MNG support and at sometime someone also asks for JNG support. And if its only 160KByte, why should we bother? I suggest to add support for at least MNG again, and consider to include support for JNG. Some organisation has to fight for open standards and in my opinion mozilla.org is doing a good job [until now...]. When one of these formts (or both) will become a W3C recommendation all or most of the work related to support for them will be needed again.
Well I will throw away the Firebird theme I was creating, since the throbber looks like complete **** if I convert it to GIF instead of using MNG. I guess I will forget another a project that I have been working on that uses MNG's. Thanks a lot Mozilla, this made my day and wasted hours of my time. Don't tell me there is alternatives, GIF isn't acceptable for themes or the images I was using and Flash isn't included by default so it is useless.
> We will only have to wait for a bug to ask for MNG support See bug #18574 which was the original request for MNG support, and has been reopened. > I suggest to add support for at least MNG again, and consider to > include support for JNG. Since JNG is a part of MNG, it only takes a few hundred bytes for the additional code needed to recognize standalone JNG files.
> See bug #18574 which was the original request for MNG support, and > has been reopened. I suggest that everybody which wants the MNG support back in Mozilla [browser] will vote for bug #18574. (I wonder why this bug (#195280) is fixed because the bug that requests MNG has about 50+ votes and this one has only 1 vote!).
>Just fyi, New throbbers were provided to the firebird/thunderbird teams and should be getting checked in soon. Cool. Have you checked with /all/ the other embeddors who might be using this code and found a solution for them as well? Clearly there's some theme authors who have been screwed over for no particular reason. Have you also checked with all the companies who might be using this support on their internal company networks? That's a much more convincing use case for these graphics formats, since you can't do anything on the web at large that Internet Explorer doesn't support, and so the statistics presented in the bug report are meaningless. I was under the impression that the mozilla policy was to be freindly to embedors, not just to dump code that they might be using because the Mozilla.org 'technology preview' browser doesn't need it. A semi convincing case has been made not to compile this code by default (although that itself would be a slow death), but I haven't seen any convincing arguments in favour of duming it entirely.
An XPI for MNG support is available at http://stud4.tuwien.ac.at/~e0225227/. Versions for Linux and windows can be found there. other operating systems may follow.
Verified broken with 2003060409 WinXP.
Shouldn't modules/libimg/macbuld/mng.xul and libpr0n/macbuilod/mngdecoder.xul have been removed?
randeg: indeed. I've now done that (and modified build/mac/build_scripts/MozillaBuildList.pm appropriately)
Hi, I am a little late on this issue, but I wish to tell you this: I was recommending my students to use Mozilla in order to examine the graphics and the compression capabilities of MNG. Even without MNG, I will still recommend Mozilla to simple users for its tabbed browsing (that I find useful), but that's a different kind of advice, without any concrete agenda. Save disk space? If that is a serious argument, then uninstall Mozilla and remain with IE. Cosmin
Just have them install MNG support from http://stud4.tuwien.ac.at/~e0225227/ and they'll have MNG support once again. Despite what a large number of people seem to think, this wasn't removed just because it saved disk space. Lack of ownership and a maintainer, large size, and tiny real world usage were among the various things that played in to this decision.
remember me, what was the problem why Netscape said they lost against MSIE? Ah, yes, you have to install Netscape. Now you have to install MNG-Support - and you might know, what that means for it's chances? Btw. has the PNG working group already thanked you for this idiotic dessission? MNG is wanted (see the votes for the readd-bug), this is VERY bad about Mozillas reputation as a stable plattform. And now look even once at comment #72.
Abstract --------- Some of you guys are about to go nuts or went it already. Maybe it's the heat or a tornado or stuff like that. I do not know. And, in fact, I do not care. But from what I can tell, some of you -- fortunately not all which still provides hope -- went definitely nuts. Details -------- I remember times when there was a strategy to push new and open formats, when new features were added to ease usage for making this the best client suite ever. And what do you do instead? You *remove* useful features step-by-step without broad support in the community and without adding something comparable in return; take for example the MailNews sidebar -- it was never seen again to date. And what makes it all worse is that you do all this with really lousy excuses like that a few KB(!) are blowing up the whole thing. Only huge protests seem to make some of you to do a reality check. See `toolbar grippies' for details. Wake up! It's the 21st century. It's an information society. Hard disk space, memory and bandwidth are as cheap as they've never been before. And, for the forseeable future, prices are falling. You can free disk space, you can buy memory, you can get a flatrate. In my humble opinion, you should care a little bit more for people's respect than for amounts of data -- just because the former is harder to earn and easier to lose. Although I can't deny that optimization is an important issue, it is definitely not everything that counts! And I just don't get it. Can't some of you see that it's *your* decisions who increasingly insult other people's hard work, people who also do their best to make Mozilla available and desirable to as many people as possible? People who do L10n, who design new themes for that many find something in Mozilla they can identify with? And as written before: Can't you see that you are about to... err, you *now* promote closed formats with an open source client suite? I was really looking forward to the modularization process coming with the next releases. I have finally accepted that there would be some features missing in some builds for in the end the result would be at least a better codebase. But with people like you on the helm, I am forced to doubt this goal is achievable. What you are doing here is not what I thought of when reading the new roadmap. In fact, you do betray the great idea you claim to contribute to. BTW, when have you just told you are going to remove MathML, PNG and, finally, CSS2 support? It seems to me that there are only a few people out there really using it (properly). So make every one of them an XPI soon!!1 :-> I am aware that Mozilla is not a democracy. I am aware that every owner spends much time in what they are doing for the part of the whole they took. (So do I, testing Nightlies, submitting bug reports, and writing cooperative shell scripts.) And it is not that I am not grateful. But to me it seems more and more that some of us do no longer care for the many, but only for the few or the one. And I am sorry that I have to write this here and now: I am getting more and more the idea that some owners think of themselves as a little dictator, caring for nobody but for themselves. (Please, prove me wrong!) Maybe a little breath of democracy here would do fine. PointedEars
Personally I want the MNG code back, so don't tell me i'm biased when i'm saying this: People that spam bugzillabugs with nonproductive comments are running the risk of having their bugzilla accounts revoked. You are not helping, you are wasting peoples time and pissing them off.
(just to add my 2c) Ok guys, let's stay professional. I, least of all, agree with what happened, but the maintainers have made their arguments and stood by it. It's water under the bridge now, and blowing our tops isn't going to help anyone. The fact that bug 18574 has made it into the top 20 most voted bugs within a few days (and easily!), shows that most peoples heads are in the right direction. Let's just focus and work on solutions now. Glenn and I have done some work to reduce the memory-footprint, but there's still a lot that can be done there. The number of votes also indicates to me that the supposedly "little used in the wild" song doesn't really fly. Remains the point of a maintainer. I said I'd take it up if I hade time, but it doesn't look like I'll have much of that luxury in the foreseeable future. Glenn's currently getting ready for stepping in there, and I can only say he's got my fullest support, wherever and whenever I can give it.
I'm just going to add my two cents. Now support for MNG/JNG support has been removed, why not create a plug-in that provides the support. This way it is an optional install and if the w3c ever decides to include this format, the plug-in can go from optional install status to standard install status.
Plugins exist, curtesy of Jason Summers and Warwick Allison. Just use Google or your favorite search engine to look for "mng plugin". But it's not the same as native support. Would MNG throbbers work via a plugin to any Gecko engine?
Most plugins are generally useless and often provide unwanted side effects. See the historical QuickTime plugin support for PNG images and other plugins when native PNG support was unavailable. PNG images always lacked the ability to be animated and, as such, the MNG format was created to fill that niche again patent and royalty free. Regarding Comment 1: At one time, PNG usage was almost non-existent and also not recognized by the W3C. It was through the support of some unpopular browsers and a minority of other programs, that it has finally started to see the light of day. Also, those programs could have benefitted from the smaller disk footprint as well, yet they chose to support a format that wasn’t “the standard.” Personally, I think this is a major mistake to remove a format before it gets started. I wonder what would have happened to PNG if the same mentality persisted back then.
how do you vote no?
Demonstration of MNG versus GIF quality Top row: original Firebird Throbber.mng (24228 bytes) Second row: optimized Firebird Throbber.mng (3986 bytes) Third row: Firebird Throbber.gif (8643 bytes) Fourth row: optimized Throbber on black Fifth row: GIF throbber on black
Here's the optimized Firebird throbber.
The XPI mentioned in comment 86 provides support which is almost 100% equal to what mozilla had before mng got removed.
Really bad idea 2 remove MNG support in Mozilla. Please vote bug #18574
Glenn: could you try the same with the turning image in the tabs, which is an MNG too?
Blocks: majorbugs
Sure; just let me know where to find the "turning image".
> mng decoder module is roughly the same size as Ok, it's big, but is it impossible to reduce the sice of the mng code? > animated gifs and flash (and possibly svg in the future) cover > much of the feature set of mng. GIF = 256 colors... Why are people using JPEG? because they want more than 256 colors? And: Mozilla supports more platfroms than macromedia does! There is *no* flash-plugin for PPC-Linux and co,(and macromedia will never port, ehrm.. compile it for pcc linux), but there are mozilla builds for this platform.
No it isn't impossible. See bug #204520. Also the PNG library is being reduced (bug #208607). So far I've taken off about 90 kbytes between the two of them, and tor has demonstrated that another substantial amount can be removed by merging the MNG library with the rest of the image library.
For the people argumenting that MNG isn't broadly used or supported: http://www.libpng.org/pub/mng/mngapps.html esp. http://www.libpng.org/pub/mng/mngapbr.html
Damn. I used this. And just fyi for the person who evaluated the lack of mng usage via a web search, the publicly accessible web is not the only environment that mozilla is used. In fact, features like this are generally adopted in specialized, controlled environments first. Anyway, the arguments for removing it are weak. Points 3-5 of the original comment are irrelevant. As for the first, it is large, but not excessively so. The second is fair, assuming lack of maintenance is causing problems. But honestly, people offered to deal with it. I will, too. Removing this was absurd, but let's get back to exactly what needs to be done for restoring it. The only actual problem was the size? Or just that no one pokes at it occassionally? Tell me what you want, and I will do it. And please, please, don't just go ripping things like this out of mozilla in the future.
Attached video modern throbber in MNG format (obsolete) —
Kai: I never found the "turning MNG" throbber that you mentioned, so I started over with mozilla/themes/modern/throbber-anim.gif (which is 23903 bytes compared to the MNG's 20858 bytes). This was a lossless conversion; I've also made a 16-color version that looks just as good to me and is under 10k.
The comparison is in PNG not MNG so you can view it without libmng.
Comment on attachment 117320 [details] [diff] [review] mng removal patch Minusing for approval1.4 since comment 77 suggests that approval isn't requested anymore. I also think that removing from 1.4 is a bad idea since it would make MNG less useful if we get it back in the build.
Attachment #117320 - Flags: approval1.4? → approval1.4-
The #1 argument in favor of removing MNG is size, correct? Reduce bloat, right? The argument is not clear cut. Some of the 160K can be regained in the skins by replacing the animated GIFs with MNGs. MNG is more space efficient than GIF. Argument #2 is lack of a maintainer? Doubtful, but maybe I could help out. I use Linux for development because Windows SDKs cost money. I have written one app that uses libpng. I have make one tiny hack to Mozilla (and it worked! bug 187187 ). I hacked up a script to convert skins from GIFs to PNG/MNG and put a conversion of the Classic skin on bug 8415. Rather not jump into "being a maintainer" cold -- better to first learn the ropes by working with people who have done it. Argument #3 "Hardly anyone uses it, so Mozilla shouldn't support it" is wrong, as many have already said.
Comment on attachment 125629 [details] modern throbber in MNG format, reduced to 16 colors Updated and relocated to bug #8415
Attachment #125629 - Attachment is obsolete: true
Comment on attachment 125530 [details] modern throbber in MNG format Updated and relocated to bug #8415
Attachment #125530 - Attachment is obsolete: true
Comment on attachment 125177 [details] Optimized Firebird throbber (new_throbber.mng) Updated and relocated to bug #8415
Attachment #125177 - Attachment is obsolete: true
verified
Status: RESOLVED → VERIFIED
Mozilla should support MNG, it sounds like the future replacement for GIF. I think that the space could be reclaimed by compressing some of the graphics used by Mozilla into MNGs. Not to mention the possibility (as mentioned) of using the MNG library to display PNGs -- which would cut libPNG out, and we would gain whatever space libPNG was taking up. I simply don't see a reason, in this case, that support for MNGs should be cut out. Look at CSS for example: a few years ago, it only worked in m$ Word, now they're all over the web; I compare this to MNGs in that they have the possibility to become the new format for animations on the web -- yet we choose to cut it out of Mozilla because we don't need it yet.
Mozilla should support MNG, it sounds like the future replacement for GIF. I think that the space could be reclaimed by compressing some of the graphics used by Mozilla into MNGs. Not to mention the possibility (as mentioned) of using the MNG library to display PNGs -- which would cut libPNG out, and we would gain whatever space libPNG was taking up. I simply don't see a reason, in this case, that support for MNGs should be cut out. Look at CSS for example: a few years ago, it only worked in m$ Word, now they're all over the web; I compare this to MNGs in that they have the possibility to become the new format for animations on the web -- yet we choose to cut it out of Mozilla because we don't need it yet.
MNG's are very useful, and both prettier and more efficient (in the case of any image larger than a few hundred bytes, as noted) than animated GIFs. I also use a platform (BSD/OS on intel and sparc) that is not, and is unlikely to ever be, supported by Macromedia. I too will add my "please put it back" vote. I've voted in bug #18574 already to voice the same sentiment there. Thank you.
Hi, I want to tell you about other interesting use for MNG/JNG and why it should be included in Mozilla again. I'm working on an optimizing proxy for low-bandwidth connections. On this proxy, the user can get images transformed on the fly from GIF to JPEG or MNG/JNG formats to reduce its size and its transfer time. For normal GIF pictures JPEG is ok, but for GIF pictures with transparency or animated the only adequate format is JNG! If you definitively remove JNG/MNG support from mozilla I would also have to drop this functionality from my app!!! Regards
The MNG-removal job isn't quite done. mozilla/xpinstall/packager/windows/browser.jst still has some (probably harmless) traces of MNG support that should be removed: browser.jst:402 deleteThisFile("Components", "nsmng.dll"); browser.jst:556 deleteThisFile("Components", "imgmng.dll");
Those two lines are intentional - so that the component is removed if we're installed over an old version of mozilla.
Well, that does make sense. I wonder why the corresponding lines in the upgradeCleanup() function for the other platforms were removed, then.
Never mind; it is all consistent.
No longer blocks: majorbugs
3 years later... PNG has become a dominating image format both on the web and in your PC. It is becoming the default format people save their photos in, and has become the required format for many print shops and studios. It is a real shame that MNG was left behind and never allowed its claim to fame. If it weren't for the decision to remove MNG from Mozilla, we might actually see it supported in today's Adobe Suite, OSX, and dare I say it, Windows Vista. If it weren't for the decision to remove MNG from Mozilla, it might actually have been adopted by AccuWeather Radar, Televised News, and the millions of websites that still cling to GIF89 ****. I call to challenge that MNG support be re-evaluated for inclusion once again.
Agreed. Disappointing we're getting APNG support instead of MNG just to save a few KB. APNG can't even be properly content negotiated for VS. a non-animated PNG so it is noxious to standards based web programming. I can give all browsers a much better experience if my server can serve intelligently based on support. MNG was the right way to do it. Of course, due to poor browser support for both, no one is giving up GIF or Flash any time soon despite their huge flaws and limitations. Low color depth, poor compression, and poor transparency support for GIF and huge overhead for Flash with poor mobile support.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: