Closed Bug 195280 Opened 21 years ago Closed 21 years ago

Removal of MNG/JNG support

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: tor, Assigned: tor)

Details

Attachments

(5 files, 3 obsolete files)

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: 21 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.