Bug 18574 (mng)

restore support for MNG animation format and JNG image format

VERIFIED WONTFIX

Status

()

P3
enhancement
VERIFIED WONTFIX
20 years ago
2 years ago

People

(Reporter: martin, Assigned: opi)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: COMMENTS GO HERE: http://forums.mozillazine.org/viewtopic.php?t=115619, URL)

Attachments

(6 attachments, 57 obsolete attachments)

84.14 KB, video/x-mng
Details
182.11 KB, application/zip
Details
254.57 KB, application/zip
Details
263.07 KB, application/zip
Details
91.31 KB, application/x-xpinstall
Details
4.31 KB, image/x-jng
Details
(Reporter)

Description

20 years ago
Are there any plans to implement animated .PNG, aka .MNG (Multiple-PNG) images?
At www.cdrom.com/pub/mng you can find technical details describing this new
image format.
There is a movement underway to completely replace .GIF images with .PNG images
on the web(because of a licensing fee that is asked for .GIF supporting
software) but that will only happen if the .PNG format will also support
animation.

Updated

20 years ago
Assignee: pnunn → newt

Comment 1

20 years ago
Reassigning to PNG component owner, Greg.
Is MNG a finalised standard yet?

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 3

20 years ago
MNG is a frozen proto-standard; it will not be officially standardized until
there are at least a couple of complete implementations available--one often
discovers subtle little problems in a spec only by writing the code and testing
the thing.  Currently there's a fairly complete MNG encoder/decoder available as
a Windows-only binary, but I don't think it's an optimizing encoder.  There's
also full MNG-LC encode/decode support in ImageMagick (i.e., Open Source), which
is sufficient to allow fully lossless conversion of animated GIFs with the sole
exception of the kind that use the one (very rare) disposal method.  The only
commercial app with any support is Paint Shop Pro (or Animation Shop, now that
it's sort of a separate product), but it hasn't been updated to the current spec
and writes an out-of-date MHDR chunk.

As for implementing MNG in Mozilla, yes, that's definitely been in the back of
my mind as the next obvious step after PNG is working correctly, and I've tried
to keep that in mind as I've rewritten bits of the PNG code.  But I personally
don't have the cycles to do it, and I haven't seen much action on the MNG list,
either.  That is, there are only three guys on the list who have done *any* real
MNG coding (I don't count my own extensions to pngcheck since it's really only a
meta-info dumper), and only two of them have released anything.  Interested
folks really should think about chipping in, perhaps starting with some
extensions to libpng to make it more MNG-friendly.  (A separate libmng probably
isn't necessary or desirable.  Feel free to steal from ImageMagick.)

Greg

P.S.  I'm changing the status to ASSIGNED to avoid getting auto-spammed, but
don't expect any progress from me for at least 6 months, probably longer.  (If a
resolution of LATER is preferable, Eli can go ahead and change it to that.)
Summary: are there plans to implement MNG (Animated PNG images)? → [HELP WANTED]are there plans to implement MNG (Animated PNG images)?
You have the option of reassigning to nobody@mozilla.org.  Adding [HELP WANTED].

Updated

19 years ago
Keywords: helpwanted

Comment 5

19 years ago
Per e-mail from Greg, he has relinquished PNG component ownership; thus, 
reassigning assigned bugs to ImageLib owner.
Assignee: newt → pnunn
Status: ASSIGNED → NEW

Comment 6

19 years ago
Reassigning to nobody@mozilla.org, for anyone who'd like to implement this to 
pick up.
Assignee: pnunn → nobody

Comment 7

19 years ago
Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed 
thru.
Assignee: nobody → leger

Updated

19 years ago
Summary: [HELP WANTED]are there plans to implement MNG (Animated PNG images)? → are there plans to implement MNG (Animated PNG images)?

Comment 8

19 years ago
Moving back to nobody@mozilla.org.  This is where the helpwanted will be 
assigned until someone picks them up.
Assignee: leger → nobody
*** Bug 37986 has been marked as a duplicate of this bug. ***
*** Bug 37986 has been marked as a duplicate of this bug. ***
info from 37986:

MNG would be a tremendous addition to Mozilla as it would offer all the
features of GIFS with no patent issues.  In addition it would allow for true
color animated images compressed as a JPEGs.

You can find more information at...
http://artpacks.acid.org/pub/mng/

Comment 12

19 years ago
Are you volunteering to write the mng component?
Great!
-P
actually not, I was just adding comments from a dupe. I have no idea where to 
even start ;)

Comment 14

19 years ago
Updating URL, removing "helpwanted", and taking bug.
Assignee: nobody → tor
Keywords: helpwanted

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 15

19 years ago
tor rocks!

Comment 16

19 years ago
tor is my hero. isn't it done yet?

seriously though, this feature is an IE5 killer. Throw a few spiffy MNGs up on
popular, anti-microsoft sites, and all their viewers will soon be using the
amazing, stupendous, MNG-capable mozilla.

Comment 17

19 years ago
It is done - I'm working on getting it checked in and helping
to solve the bugs that prevent full integration (see the
dependencies for this bug).
Depends on: 41333, 41831, 42199

Comment 18

19 years ago
tor:

On which platforms have you tested the code?  If someone would
volunteer to  test on wintel and/or mac (and maybe linux if 
you tested on solaris) would be a huge help. 

-pn

Comment 19

19 years ago
Personally tested on solaris/sparc and linux/ia32.  I have written diffs
for the win32 build system, but don't have a system available to attempt
a build.  Haven't figured out the mac build system enough to attempt to
make the necessary changes there.

My thought was to get this code checked in behind a --enable-mng configure
flag for unix (plus perhaps the win32 changes), then work on getting the
other platforms running.

Comment 20

19 years ago

Comment 21

19 years ago
uh.
changing the configure files won't affect win or mac either way.
We can just not modify the win/mac make scripts to pull in mng.

And we don't want to modify the mime sniffer. Really. 
Not until we know why necko is being stupid about understanding the mime type.
Or why the loader isn't finding the decoder component.
-P

Comment 22

19 years ago
pnunn, as part of the MNG landing I would like to checkin the attached patch
for if.cpp to add mng/jng to sniffout_mimetype().  This allows mozilla to
handle MNG/JNG files from servers that don't attach the appropriate mimetype.
This patch also reindents the ART chunk to match the rest of the code and
includes the gross hack to let the MNG decoder handle two mimetypes (by
pretending JNG files are video/x-mng).

Along with the unix build system changes I've made the necessary changes
to config/config.mak and modules/libimg/makefile.win that should allow
mng-capable builds on win32 by setting MOZ_MNG=1.  The build system
changes have been reviewed by cls.

Comment 23

19 years ago
I don't want the mime sniffer changes checked in.
We have to respect what a web server sends. Assuming
that we know better what mime type is sent is arrogant
and ultimately confusing.

If the component loader is not finding the mng decoder, we
need to find out what's wrong. Not paste over the problem
with 'fixit' code.

If you need to test how the component loader is working,
reference the mng test file by way of an html page, with
an <img> tag. This will assure you the data is routed to
the image lib.

The mime sniffer is there to override setting that may occur
on certain classes of browser images. But if the data stream
doesn't match anything in the mime sniffer's list, the component
should be loaded with the mime type sent from necko.
   This is the part that is broken. There should be a way to
   add a mime mapping with file extension in necko.

I'm adding Jud and Gagan to this list so they are aware of
the issue.

-P

Comment 24

19 years ago
If you say that we should believe what the server tells us, why is the
mime sniffer there at all?  Currently if I rename a gif file to foo.png,
mozilla will ignore the image/png mimetype and feed the stream to the gif
decoder.  Mozilla should trust that the mimetype and attempt to decode it
with the png decoder.

Comment 25

19 years ago
The mime sniffer is there for some of the basic image mime types
that are commonly used as part of the browser and browser chrome.
It minimizes some of the more common place user error screw ups.

But for the browser to be able to have a mechanism to drop in new
image format decoder components, we have to trust that some users
somewhere have a clue and can create a new mime type mapping. 
If we police all the data streams, then we should test all data streams
in necko just in case they _might be_ image data. And the browser
would be so slow it would be unusable.

I see these as the basic issues:
   1. Where should the user add the mime type mapping to necko?
   2. Is the component loading correctly? Is the correct mime type
       passed through to imglib? Why can't the component be loaded?

If we have the answers to these issues and it makes sense to add
in a _temporary_ mng signature to the imglib mime sniffer until
we can get the correct structures in place in necko, I'd be ok with
checking it in. But I don't want to do it, until we have a clear
view of what is wrong and how to fix it.

-P

Comment 26

19 years ago
ps. I can see cls oking the X config system changes, but
can he really test the win changes? I had the impression he is an
unix only guy.
-P

Comment 27

19 years ago
Since the mng/mngcom subdirectory makefile.win are untested, I'll leave off
the win32 build system changes in my checkin and attach them here for the
adventurous.
 

Comment 28

19 years ago
Code checked in along with unix build system changes to add a --enable-mng
option.  Here are the current limitations (which will drop away as dependent
bugs are resolved):  MNG files, limited to roughly 256Kb, must be specified
inline (i.e. <img src="foo.mng">).

For people on win32, hopefully all that's needed is applying the following
patch, setting MOZ_MNG=1, and making in modules/libimg.  More realistically
you'll probably need to tweak modules/libimng/mng{com}/makefile.win.  Please
try it out and report any successes or patches needed.

We could use some help from a MacOS person to get it building there.

Index: modules/libimg/makefile.win
===================================================================
RCS file: /cvsroot/mozilla/modules/libimg/makefile.win,v
retrieving revision 3.6
diff -u -r3.6 makefile.win
--- makefile.win        1999/11/06 03:31:07     3.6
+++ makefile.win        2000/06/12 23:40:43
@@ -20,6 +20,10 @@
 
 DEPTH=..\.. 
 
-DIRS = public src public_com png pngcom jpgcom gifcom
+DIRS = public src public_com png pngcom jpgcom gifcom \
+!if defined(MOZ_MNG)
+       mng mngcom      \
+!endif
+       $(NULL)
 
 !include $(DEPTH)\config\rules.mak

Comment 29

19 years ago
tor:
This is Great! I can't wait to play with this...
-P

Comment 30

19 years ago
[#whatever pnunn said!] 

Comment 31

19 years ago
Most of the thanks should go to Gerard Juyn (gerard@libmng.com), who wrote
the excellent libmng and graciously made modifications to the library to 
ease integration with mozilla.

Comment 32

19 years ago
tor:
I'm going to a meeting today to find out who needs to work
on user specified mime mapping (like helper apps, but with
components.). I will be doing some tests to see where the mime
type is 1)not getting set  2)if set, where it is lost.

fyi
-P
To get libmng to build on Windows, I indeed had to tweak makefile.win.

Comment 35

19 years ago
Copy/paste/modify error on my part - patch checked in.  Thanks!

Updated

19 years ago
Blocks: 8415

Updated

19 years ago
Depends on: 43684

Updated

19 years ago
Summary: are there plans to implement MNG (Animated PNG images)? → MNG tracking bug

Comment 36

19 years ago
The MNG decoder was turned on by default today on all platforms,
and is now in the nightly builds.  Give it a try and if you find
any bugs other than the current dependencies of this bug please
file a bug against me.  Thanks.
Gamma correction dosn't seem to work on Windows. Added dependency on bug 44866
Depends on: 44866

Comment 38

19 years ago
Insofar as (1) basic MNG support is enabled on all platforms, (2) basic MNG
support works on all platforms (well, Linux and Win32, at least), and (3) MNG
gamma correction works (tested with Win32 build 2000072008), this bug should not
block 8415--everything necessary for chrome support is in place, as far as I can
tell.  The only MNG features on Gerard's test suites
(http://www.libmng.com/MNGsuite/ and http://www.libmng.com/JNGsuite/) that do
NOT work, as far as I can tell, are color correction--either via chromaticity
chunks or ICC profiles--and JNG.  But neither is a blocker for chrome.

Greg

Comment 39

19 years ago
MNG is still not working in chrome. I have finished a new skin for bug 8415, and 
the MNGs I attempted to use did not work. They are included in the skin for use 
as a test case. Just modify communicatior/skins/brand.css to test the throbber.

Comment 40

19 years ago
As I said in 8415, MNGs not working in chrome is most likely due to bug 

41333.

tor - is there an issue with MNG on Mac still (this is implied by an earlier 
comment)? If so, does it need fixing by RTM?

Gerv

Comment 42

19 years ago
I don't know of any mac-specific problems other than the gamma

correction, which affects mac more than other platforms.

Updated

19 years ago
QA Contact: elig → tpreston

Comment 43

18 years ago
*** Bug 66963 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Blocks: 66967

Updated

18 years ago
Keywords: meta

Updated

18 years ago
Depends on: 66976

Updated

18 years ago
Blocks: 66979

Updated

18 years ago
No longer blocks: 66967

Comment 44

18 years ago
MNG support does not appear to work in Build 20010430 Win98. Is anyone else
experiencing this problem?

Comment 45

18 years ago
libpr0n (the new image library) does not have a MNG decoder.  I have half of
such a decoder in my tree - works fine, but leaks all images.  I'm planning
on getting back to it before 0.9.1.
> libpr0n

Ha ha very funny.  Now please change it.  Political enemies of the
organizations that supported libpng/libmng in the first place could
have a field day with it.

Glenn

Comment 47

18 years ago
Image library name discussion --> bug 66984

Comment 48

18 years ago
randeg: libpr0n is the name of the entire new image library, not just the 
PNG/MNG part. Besides, it's also called imglib2 (IIRC) if you want to be 
politically correct.

Not sure what you mean by "political enemies of the organizations that 
supported libpng/libmng". It's an image rendering library, not welfare reform.
> Not sure what you mean by "political enemies of the organizations that 
> supported libpng/libmng". It's an image rendering library, not welfare reform.

enemies: Radio talk show hosts and the like.
organizations: Government laboratories
support: Tangible support, e.g., web/ftp hosting

Comment 50

18 years ago
The progress of MNG is disgusting (it's literally moving backwards). Adding
helpwanted, regression, and *strongly* suggesting for nsbeta1. Many sites out
there still credit Netscape 6/Mozilla with having MNG support from the days when
it actually *did*. Currently Mozilla doesn't support any animated image format
except Unisys' patented GIF89a format.
Keywords: helpwanted, nsbeta1, regression
removing nsbeta1, netscape only
Keywords: nsbeta1

Comment 52

18 years ago
doronr: By your keyword change I am assuming Netscape has fixed MNG for Netscape
6.1. Is this true?
No. He's removing the keywords because they are no longer relevant.

tor has MNG in hand; he's waiting for help with building it on Mac and Windows,
AIUI. Patience :-)

Gerv

Comment 54

18 years ago
Gerv: Please explain to me how nsbeta1 is no longer relevant.
AIUI, nsbeta1 was NS 6.1 PR 1, which has happened.

Gerv
My apologies; I was wrong. nsbeta1 is not specific to any release, and no-one
except Netscape employees should be removing Netscape keywords.

Gerv
Keywords: nsbeta1

Comment 57

18 years ago
IIRC no one removes the nsbeta1 keyword. it is replaced with nsbeta1- if
Netscape doesn't feel it is necessary. However, the next nsbeta1 is going to be
a while in coming, but at least it'll be there for PDT. :-)

"Bugs which have been rejected for consideration in the next Netscape release
will have the nsbeta1 keyword replaced with the nsbeta1- keyword."
--Keyword Description

Comment 58

18 years ago
Yes, and only @netscape.com should be setting nsbeta1(+|-).

Comment 59

18 years ago
I think until MNG works again, we need to put up a release note that MNG *will
not work* with affected versions. This is particularly important since some
sites still say that Mozilla supports MNG.
Keywords: relnote
I've seen that there is a directory modules/libpr0n/decoders/mng in the Mozilla
Tree - how can I enable the MNG Decoder?
Is it working on Win32?
If not, what needs to be done?

Comment 61

18 years ago
Should run fine on windows, though personally I haven't tested the new
decoder on that platform.  To build it cd to modules/libpr0n/decoders/mng
and do a make -f makefile.win .  Any problems encountered should be
reported in bug 66976.
Zach is supposed to be producing the Mac project files for MNG, but he tells me
he's too swamped to sort it out.

Is this the only thing blocking turning MNG on? Can someone else produce these
files?

Gerv
I just asked on irc.mozilla.org if anybody would like to create the Mac Project
Files for the MNG Decoder, and peterv said he would do it if he had time; I
should remind him in a day or two.

Couldn't the MNG Decoder turned on on the other platforms while Mac Project
Files are missing?
The REQUIRES Line in the Makefile is completely wrong, the following will work.
I haven't checked makefile.win, but I assume that it needs the same changes.

Index: Makefile.in
===================================================================
RCS file: /cvsroot/mozilla/modules/libpr0n/decoders/mng/Makefile.in,v
retrieving revision 1.4
diff -u -r1.4 Makefile.in
--- Makefile.in	2001/09/18 13:38:03	1.4
+++ Makefile.in	2001/10/01 13:37:11
@@ -32,6 +32,12 @@
 REQUIRES	= $(MNG_REQUIRES) \
 
	  $(JPEG_REQUIRES) \
 
	  $(ZLIB_REQUIRES) \
+
	  xpcom \
+
	  necko \
+
	  gfx \
+
	  gfx2 \
+
	  imglib2 \
+
	  timer \
 
	  $(NULL)
 
 CPPSRCS
	= nsMNGDecoder.cpp nsMNGFactory.cpp imgContainerMNG.cpp

Comment 65

18 years ago
gerv: mac project files, getting r/sr on the mng decoder, and the minor build
tweaks to turn on mng by default are all that's left.
tor: are you chasing r and sr on the decoder at the moment?

Gerv

Comment 67

18 years ago
gerv: no - I was waiting until it was built and tested on all tier-1
platforms before trying for a review.  A four month old review (when
the decoder was ready) would be considered stale.

Updated

18 years ago
Blocks: 104166

Updated

18 years ago
Keywords: nsbeta1
Should this bug still depend on 41333, now that MNG is on the trunk?

Glenn
Probably not.

Gerv
No longer depends on: 41333

Comment 70

18 years ago
Right, but it does need to be fixed.  The number of tables that needed to
be modified to add a new image mimetype is insane.  If Christian hadn't done
the hard work of finding all of them for ICO I probably wouldn't have bothered
with a full integration of MNG.

Since MNG is now turned on everywhere and chromacity correction is somewhat
low profile, I'm closing this bug.  If you find MNG support bugs, please file
them in bugzilla against me.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 71

17 years ago
Verified MNG's working on win XP build 2002032803, linux build 2002040211 and
Mac OS X build 2002040203
Status: RESOLVED → VERIFIED
There is a move afoot to remove MNG/JNG support (See bug #195280), therefore
this bug should be reopened.  A vote for this bug should be considered a
vote against 195280.  Glenn

Comment 73

16 years ago
Help still wanted (libmng maintenance/support within imagelib), regression
threatened (bug #195280).  Not sure if reopening will work, but trying anyway...
Status: VERIFIED → REOPENED
Keywords: meta, nsbeta1, relnote
Resolution: FIXED → ---
Summary: MNG tracking bug → retain support for MNG animation format and JNG image format

Updated

16 years ago
Depends on: 204520
I'll work within libmng to explore ways to reduce its footprint.  Glenn
Now that bug #195280 has been "FIXED", please change this bug's title from
"retain support for MNG ..." to "restore support for MNG ...".    Glenn
Summary: retain support for MNG animation format and JNG image format → restore support for MNG animation format and JNG image format

Comment 76

16 years ago
Reassigning since the bug is currently assiged to the person who CAUSED this bug.
Assignee: tor → randeg
Status: REOPENED → NEW

Comment 77

16 years ago
Posted patch Reversal of mng removal patch (obsolete) — Splinter Review
This is just tor's patch for bug 195280 (attachment 117320 [details] [diff] [review]) reversed. It 
only affects the build system.

Comment 78

16 years ago
This bug has 30 CCs and 39 votes. 50 of either will make this bug block bug 163993.

Comment 79

16 years ago
Posted video MNG testcase

Comment 80

16 years ago
Give up Mozilla is doomed - at least if they go on removing good an interesting
features like this.
Tim:  I'd be interested in seeing an alternate patch that puts MNG/JNG
support in the extensions instead of back in libimg2.

Updated

16 years ago
Blocks: 163993

Comment 82

16 years ago
Removing MNG saved what, 300kb on my 40+ GB drive? Whoop-de-doo!

Comment 83

16 years ago
Re: comment 81, I'd love to, but build config changes are out of my ballpark
("my" patch was just running tor's patch through a reversing program).

Updated

16 years ago
Severity: enhancement → major

Comment 84

16 years ago
Posted file Relocate old MNG decoder files (obsolete) —
Here is a zip containing the old files in a new location 
(extensions/mng).  I fixed the depth in Makefile.in, which is the only 
change at all in any of the files.

--- modules/libpr0n/decoders/mng/Makefile.in	2003-01-30 00:53:12.000000000
-0500
+++ extensions/mng/Makefile.in	2003-06-04 10:53:52.000000000 -0400
@@ -17,7 +17,7 @@
 # Contributor(s): 
 #   Tim Rowley <tor@cs.brown.edu>
 
-DEPTH		= ../../../..
+DEPTH		= ../..
 topsrcdir	= @top_srcdir@
 srcdir 	= @srcdir@
 VPATH		= @srcdir@

I don't know what changes would need to be made to other parts of the build
system (probably the extensions/Makefile.in file and maybe the configure.in
file).
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.

Comment 86

16 years ago
Tim wrote:
> Created an attachment (id=124907)
> Relocate old MNG decoder files
> Here is a zip containing the old files in a new location 
> (extensions/mng).

Moving MNG support to extensions/mng/ may not be a good solution since much of
the stuff in extensions/ is not part of the default build and/or will be
explicitly turned-off by some vendors if there is a way to do so (bug 133534 is
one example how things can go really worse... ;-( ).

Comment 87

16 years ago
Is there an existing architecture to make image decoders pluggable and/or
in-/excludeable at build time?
If not, we should put one in place right now, as we apparently have the need for
that.
kairo: we have both. at compile time, there's --enable-image-decoders (iirc);
and at a later time, you can just drop in a component (well almost, but it works
quite good).
mozilla/extensions exists so that vendors/embedors/distributors/whoever can
disable things that they don't need, which is exactly the case for MNG as well
as many other things in mozilla (including .bmp and .ico).

Why would Crocodile Clips need to include the code for MNG decoding in their
software for teaching math? Or why should ACME-Handhelds need to include a
xprint in their handheld browser? The answer is obviously that they don't.

If someone doesn't want to ship with a certain part of the browser we should not
force them to. That will only cause distributors to choose other browsers.

So the fix for this bug is to find someone who is willing to own MNG (which it
looks like Glenn is), and then place it in mozilla/extensions

Comment 90

16 years ago
So why do we have to move it to extensions and not use --enable-image-decoders
for enabling/disabling? I think it would keep a clearer structure.
Anyway, it's good to see MNG support being at least optional, if not enabled by
default, again.
i just stumbled about this occasionally... but i'd like to see the return, too.
especially since merging MNG into libimg2 and removing redundant code (PNG)
would be more than acceptable in my opinion. there's nothing more beatiful than
8bit transparency. and as said in bug 195280 gerald would volunteer to maintain
this. but well. should we carry this discussion over to mozillazine? maybe this
way more people would get to know about this. and help to solve the issue.
> Moving MNG support to extensions/mng/ may not be a good solution

Leaving it where it was is of course a better solution, but the module
owner doesn't want it there and has already removed it.  Putting it in
extensions/ is a stopgap measure.

>So the fix for this bug is to find someone who is willing to own MNG
>(which it looks like Glenn is), and then place it in mozilla/extensions

Yes I am willing, although I don't seem to be empowered to mark the bug
ASSIGNED.  I will need to rely on those who are "empowered" to help out.

Glenn


Comment 93

16 years ago
If you want the permissions to modify/confirm a bug you just need to shoot an
e-mail to <gerv@mozilla.org>.
Status: NEW → ASSIGNED

Comment 94

16 years ago
I don't think this bug should depend on bug 44866. That's color-correction stuff
that's far from being implemented anywhere in Moz AFAIK.

Updated

16 years ago
Blocks: 44866
No longer depends on: 44866
(Assignee)

Comment 95

16 years ago
Will help where I can, but I've no experience with graphics.

Comment 96

16 years ago
Just so these XPIs are as available as bugzilla is, here is a zip of the web
page and XPIs mentioned in comment 85.

This is split into four files since the max size is 300K. You only need the one
for your platform.

Comment 97

16 years ago

Comment 99

16 years ago

Comment 100

16 years ago
Please let's stop crippling away important Mozilla features to make it more like
Internet Explorer.

Mozilla was meant to be much more than a simple browser. Mozilla paved the way
for the best support of PNG graphics in the industry. It will pave the way for
JNG and MNG as well.

I've juste added my vote here. 151st one.

Keep up the good work, gang.

- Jacques

Comment 101

16 years ago
Since Glenn is taking care of moving the MNG support to extensions/mng/, why not
restore the old imgmng module until the Glenn's MNG extension is finished?

I am trying to understand why you want to remove the former native MNG support,
but I cannot understand why it must be removed *now*, and cripple some of the
upcoming Mozilla releases!

Cosmin
Blocks: 177670
Blocks: 48893
I've just placed a comparison of the Firebird Throbber.mng from before
the MNG removal, an optimized version of it, and the GIF version that
was recently provided to the Firebird crew, in bug #125280 comment #100
along with a copy of the optimized MNG throbber.  I used Greg Roelofs'
"pngquant" and some of my own tools to reduce the filesize from 24kbytes
to under 4kbytes without any effect on its appearance.  The GIF is over
8kbytes.  Judge for yourself how it looks against the black background.
I suppose it could be optimized too but I don't have anything that writes
compressed GIFs.
The throbber demo is in bug #195280 comment 100.  Sorry about the typo.
Note that the comparison is in static PNG format, not MNG, for the benefit
of those who are using a MNG-hobbled browser.
Blocks: 198591

Comment 104

16 years ago
I dont want a browser without MNG support.
I DONT WANT GIF/flash copyright images/animations!!!!!!

I think that MNG can find a manteiner if reeintroduced.

Comment 105

16 years ago
I concur with some other posts above, adding that the *final candidate* stage is
not when this kinds of surgery should take place! That's quite ridiculous.

Comment 106

16 years ago
I concur with some other posts above, adding that the *final candidate* stage is
not when this kinds of surgery should take place! That's quite ridiculous.

Comment 107

16 years ago
It's only been removed on the trunk not the branch

Comment 108

16 years ago
Support for MNG should most definitely be restored to Mozilla. Firstly it is the
only way a web site using open standards can implement animation. Secondly, with
the native implementation (rather than plugin) provided by Mozilla one can
insert an animation as easily as inserting an image, which avoids all the
embed/object pain when trying to support XHTML.

Thirdly, a big vote of thanks to the MNG/PNG team, who have made a big
contribution to the future interoperability of the web.

Oh - and fourthly - I'll have to find another reference browser as I use quite a
few mings on my site...

Comment 109

16 years ago
As many, many people here, I'm all for restoring the MNG plugin. Even after reading 
the developers' reasons, I fail to understand why they removed something that was 
usable. Here's my vote. 

Comment 110

16 years ago
Please put it back into the build.  As someone stated before.  NO PATENT ISSUES
with this format.

Comment 111

16 years ago
People, don't add useless comments like 'ooooh, this has to get back in', that
will NOT help. Just vote for the bug, help with development, make a strong case
with reasons why MNG should be included again. It's a lot better to post nothing
than to post something like 'you NEED to add this again' :\ Just vote and then
either wait or help.

And please read the Bugzilla docs :D

Comment 112

16 years ago
I believe this bug now has more votes than any other bug ever.  At 402 votes,
it's passed the PGP RFE.  And it got most of them in about 9 days.  
FWIW, I'm developing a bioinformatics tool that was to use MNG for genome
mutation visualization.  Things like that aren't ever going to show up on an
image search because they're generated dynamically.
Does drivers have an official stance on this issue?

Comment 113

16 years ago
The same question has been nagging me but I've been hesitant to ask it: at what
point are the votes important?

Comment 114

16 years ago
Have a look at http://www.mozillazine.org/talkback.html?article=2702&message=21
for Asa Dotzler's take on votes vs action. 

To summarize, votes aren't taken into account at all in and of themselves, if
Netscape decide to work on any RFE, they will typically work on the ones with
more votes first. Votes on groups of bugs along the lines of 'implement this
feature'/'don't implement this feature' (such as this one and its friend)
typically aren't worth the paper they're printed on.

Comment 115

16 years ago
Lewis: All of your statements are valid and _do_ apply to a bug where there is
some work to be done.

However, this is not such a bug. This is a simple management decision. There is
no work involved in 'fixing' this bug. I realize that there is no method by
which people may vote against this bug but perhaps the sheer quantity of
attention to this bug prompts further exploration, yes?

And if indeed our votes "aren't worth the paper they're printed on", you just
insulted 400 voters. So which is it? Should I keep my vote here more move it to
a bug "worth something"?

Perhaps a poll at mozillazine would provide a more representative sample of the
Mozilla user base's opinion?
Sure you can vote against this bug.  To do so, vote for bug #195280.

Comment 117

16 years ago
Amusingly, bug 195280 has *lost* votes.
I believe it had 2.
Now 1.

Could be because it was "fixed" I suppose.

Comment 118

16 years ago
Jason: these are not my opinions, but a summary of those found at
http://www.mozillazine.org/talkback.html?article=2702&message=21 . 

I suggest you go and read the whole posting, especially the third paragraph
("Even if you just look at Bugzilla account holders as a representative sample
of end-users (I dispute this heavily but for the sake of argument we can discuss
it) then you've still got less than 1/2 of 1% of Bugzilla users voting for a
particular feature or bugfix").
> There is no work involved in 'fixing' this bug.

This is untrue. There is a lot of work, in particular, someone has to own the
MNG code, fixing bugs as they are found, maintaining the code in the face of a
changing Gecko, and working on MNG's significant memory and disk footprint. (I
believe there is a volunteer at the moment, I'm just pointing out that this is
still a lot of work.)
I had a discussion with pavlov about this yesterday. He doesn't care about votes
AT ALL: "<stuartk> heikki: if i see like 250k votes, that might be signifigant"
(he got flamed a lot for that, even by other developers, as those numbers are
idiotic and can never be reached)

It's still more interesting to discuss the arguments against MNG:

1) filesize - this got reduced by around 50%, maybe more.
2) GIF and Flash cover this - flash is closed source, about GIF we only need to
see the new throbber on a dark background, how good this is covered.
3) little used - there is only few use for animated images at all, as you also
see only few ani-GIFs. As MNG isn't supported in MSIE for now, 2% of all
animaged images would mean it's more successfull, than Mozilla is ;). Also we
have comments, that it IS used.
4) W3C - just see comment #3 here.

Comment 122

16 years ago
>> There is no work involved in 'fixing' this bug.
>This is untrue. There is a lot of work, in particular, someone has to own the
>MNG code

Fixing this bug simply requires reversing the patch which removed the support -
that is not a lot of work. Whether it's a good idea to have un-owned code in the
tree (or even in the build) is another question, but AIUI, there's quite a bit
of it around.

and even if there is a maintainer, that's only part of the reason it was removed
- another reason was that there is virtually no usage of MNG on the web.

> Yes, this bug has currently the largest number of votes in Bugzilla
> [huge query string]

that, in itself, doesn't change anything. PGP (now pushed down to second place)
has had several hundred votes for a couple of years, and nobody is doing
anything about that.  and if you must post query URLs, there's a bookmarklet
which shortens them to something reasonable at
http://www.squarefree.com/bookmarklets/mozilla.html
>PGP (now pushed down to second place) has had several hundred votes
>for a couple of years, and nobody is doing anything about that.

The difference is that MNG *was* supported in Mozilla since DEC-2001 and then
was suddenly removed.

Comment 124

16 years ago
Well, now that we know that votes on this bug are completely disregarded (per
comment #121), I'm moving my vote from here to bug #204520 which is where the
work on getting MNG's footprint reduced is occuring.

And Mr. Developer: in the future, please don't tell us to shut up and "just
vote" for something when -- in fact -- you don't care. You just wasted a whole
lot of our time and insulted us, to boot.

Comment 125

16 years ago
Look. People working on the Mozilla codebase can only act this way because the
rest of the Bugzilla community allows it. If people staged some sort of strike
and refused to do anything on Bugzilla (like confirm bugs, verify, develop
testcases, etc.) that might have some sort of effect. If they don't listen to
the votes, then force'em to.

Comment 126

16 years ago
> If they don't listen to the votes, then force'em to.

from Bugzilla Etiquette (http://bugzilla.mozilla.org/page.cgi?id=etiquette.html):

No obligation. "Open Source" is not the same as "the developers must do my
bidding." The only person who has any obligation to fix the bugs you want fixed
is you. Never act as if you expect someone to fix a bug by a particular date or
release. This is merely obnoxious, and is likely to get the bug ignored.
but you can't force anybody to help an app, which moves into the wrong
direction. And this happenes here, if the community (!= all users!) are totally
ignored.

Comment 128

16 years ago
There are many people who work on the Mozilla Project in a capacity other than
as coder. We do all kinds of things to free the coders' time up to do coding. If
we are going to do that work so that they can code, they could at least have
some deference to that instead of sending us a collective "bite me". I don't
think it bad ettiquette to say, "if you don't do the work we want, we aren't
going to do your grunt work anymore."

Comment 129

16 years ago
**** people off is never a good strategy.  You can catch more flies with
honey than vinegar.  Let this bug simmer for a while.  Posting "me too" comments
(kind of like this one :-) only spam everyone who has voted for this bug and
fill up mailboxes making more people apt to unvote/unCC themselves.  And
remember, at the end of the day, it's just a web browser, and it's just a file
format.

Comment 130

16 years ago
I think the reality is that tough decisions do have to be made and in this
instance, one has already been made. The comment that votes are irrelevant was
probably not communicated in the most diplomatic way.... for the most part I'm
sure it is true, otherwise in cases such as this we'd always wind up having to
bow to demands.  It is a tough decision.

I think the point being made was that decisions are made and votes won't change
that. The votes are merely to aid the order in which bugs are fixed.

All that said, I don't think it hurts for people to vote if they really believe
in something such as this. But no one should expect that 1000, or 10,000 votes
or whatever means the decision will be reversed. But if you believe in this and
you vote for it then in reality is must have a slight effect on future decisions.

And thats democrasy (even if I can't spell it!).

Myself, I would like to see this feature in place - it does seem like a Good
Thing(TM), but the people making the final decisions know this. They are aware.
They do understand. They do care. Unless I can commit the time to doing the
development myself, then I can't really complain; people do what they can to aid
the common cause. If anyone is sooo upset about this decision, then be proactive
in trying to reverse it - don't start wars!!

Peace and love everyone!  Have a great weekend. ;)
I am working with the imglib maintainers on defining a set of criteria that they
want to be met in order to get MNG back in. As soon as they are agreed, I'll let
everyone know what they are.

In the mean time, please continue to vote for this bug if you so wish.

Gerv

Comment 132

16 years ago
Thanks Gerv, it's really good to see someone @mozilla.org taking care of getting
this discussion in a good shape.
Please cqare to take a look that the creteria can really be met, so we don't get
"you must have 250k votes" or something like that. Again, thanks for steppoing
up and trying to get that discussion and work back to some use again.

<thought mode="crazy">My theory grows to be that pavlov wants MNG to be broadly
supported and well-supported, so he tries to make tons of people upset about the
topic, so that they all do really care of what's happening in the future and
start using MNG for almost everything, as soon as it's supported again</thought>

Comment 133

16 years ago
Just an additional argument for keeping it: I read on German IT newschannels that
there is an ongoing patent issue with the JPEG format. Not very definitive yet,
but maybe the future will bring us bad news.
So having an additional open format at hand could be a big advantage, even if it
is not widely spread yet. Maybe that could also be a reason to begin to ACTIVELY
spread it now.
For the love of god people, this isn't a forum! Shows of moral support, "that's
great," personal attacks, and "me too" posts have no place here. As this is a
codebase steering issue, and not an actual bug (intended functionality, or lack
thereof is not a bug) the arguments for and against bringing back MNG may have
been warented, but only when the arguments made were contruvite and helpful.

I don't think it's really impossible to argue for MNG to be reimplemented
without breaking the rules in the Bugzilla Etiquette. That means no pointless
comments, no trying to FORCE the developers to do what you want, and NO personal
attacks. The nastiness out of some parties is really just getting inappropriate
for a software development bug tracker. I believe "Hey, something's being done?
I think that's great" is also not appropriate.

That being said, I want MNG back in the codebase, but if the developers can't
agree to do it, there's only three things you can do. You can find another
browser, create a set of patches against the trunk which re-adds the
functionality, and release your own binaries, or if there really are enough
people disatisfied with how this was handled with coding skill and time to
maintain such a massive project, as is open source tradition, you can always
fork the codebase. I hope it doesn't come to that last option, but it's always a
possibility, and in someways, it could also be interesting, assuming enough
developers could be found to maintain both Mozilla and the forked project.

Anyway, useless comments down to a minimum, please? Not everyone likes waking up
to 15 e-mails in their mailbox.

Oh, and before anyone else posts something to the last post which I just got in
my e-mail, I'm not really sure what JPEG has to do with MNG. JPEG is a lossy
static image format, and MNG is an animation format for PNG, which is loss-less.
The two are about as unrelated in usage as possible for raster image formats
capiable of 24-bit colour. True JPEG can be hacked to do animation in Mozilla,
but I haven't really seen it used outside of streaming webcam software, which
uses a Java App for IE, in years, because IE, and many other JPEG renderers do
not support animated JPEGs.

Comment 135

16 years ago
<offtopic>I'm sorry for this spam upfront, but if I don't say it on here,
somebody will.  Notice this bug includes JNG which is the JPEG Network Graphics
format, which is basically JPEG-in-MNG.  So before adding more spam to
everybody's mailbox complaining about complaining, get the simple facts
straight.  Though I do agree that that post did in fact have nothing to do with
this bug (if JPEGs are in trouble, then so is JNG, another issue
altogether).</offtopic>

Thanks for responding, Gerv; glad to know actual progress is being made.  NOBODY
ELSE NEEDS TO COMMENT HERE UNTIL GERV GETS BACK TO US.
Whiteboard: DO NOT COMMENT UNTIL GERV GETS BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG

Updated

16 years ago
Flags: blocking1.4?
Flags: blocking1.4?

Updated

16 years ago
Flags: blocking1.4-

Comment 136

16 years ago
Setting blocking1.4- as MNG suppport has not been removed from the 1.4 branch
and thus will be in 1.4 final.

Comment 137

16 years ago
The MNG decoder is 300k? Oh lord please tell me it isn't 300k! I mean I only
have a 70gig drive here people, you all act like this is the 21st century or
something, sheesh. And talk about that memory footprint, I need to conserve my
512megs of RAM to make sure AIM runs smoothly and none of that 300k bloat taking
up all my RAM. *rolls eyes*

Comment 138

16 years ago
Since bugzilla isn't letting me vote without comment, I'm just stating that I'm voting to change 
resolution to FIXED to support the MNG/PNG format. Good luck to all involved in getting it 
reinstated into the Moz trunk.

Updated

16 years ago
Flags: blocking1.4- → blocking1.4+

Updated

16 years ago
Flags: blocking1.4+ → blocking1.4-
See bug 209439 - "Need ability to find 3rd-party extensions through .xpi".
Perhaps if this were available as a toolkit-level addon, it wouldn't need to be
distributed with Mozilla and could be downloaded into the GRE on demand. Of
course, this means nothing for the XPFE version of Mozilla as long as we carry it.

Tux: The size is not an issue for hard drive space, but for download time.
>Perhaps if this were available as a toolkit-level addon,

hm? What do you mean with toolkit-level addon?

> it wouldn't need to be
>distributed with Mozilla and could be downloaded into the GRE on demand.

currently, you can't install extensions into the GRE, and it looks like that's
as intented, as written in another bug.

> Of
>course, this means nothing for the XPFE version of Mozilla as long as we carry it.

?
the xpfe version of mozilla does not currently include the mng decoder

however, my xpi should work for all versions of gecko.
> currently, you can't install extensions into the GRE, and it looks like that's
> as intented, as written in another bug.

biesi: see bug 209439 (which really needs a better description)... I am working
on a mechanism that will allow "GRE extensions"... there is a whole dependency
tree to accomplish before this become reality, but it will happen.

> Of
>course, this means nothing for the XPFE version of Mozilla as long as we carry 

The XPFE mozilla uses the GRE just like Phoenix does...

Comment 142

16 years ago
Nice. Perfect. Just when I started to use MNG. Thanks a lot guys. 

Is there a way to get that xpi working in Mozilla Firebird?
It seems likely that when MNG is restored to the trunk, it will be
in a degraded form that doesn't handle 16-bit samples or Delta-PNG datastreams.
If so, is there a way to use an XPI to regain full MNG capability?  Note
that it would be possible to regain full MNG capability by building with
the system libmng instead of the embedded one, but I think only a small
minority of users will want to do that or even be capable of it.

Comment 144

16 years ago
Why only degraded lib?
How much size does it save?
It's a tradeoff of size versus removal of features.  The specific amount
saved is platform-dependent.  For specifics, after Gerv gets back to us,
see bug #204520.  But rest assured that Gerard and I are making pretty
good progress.
The XPI should work just fine in Firebird; though I haven't tested it. does it
not work?
It is claimed in mozillazine "Fb" forum, near the end of the thread on
MNG/JNG removal, that it does not work with Firebird.

Comment 148

16 years ago
In my personal opinion, it is a good idea to drop the 16-bit support since only
8 bits are rendered anyway, but it is not a good idea to drop Delta-PNG.
Notwithstanding the portability of MNG files, Delta-PNG is one of the key
features of MNG, that can make a big difference in compression, compared to GIF.

I also wish to make a suggestion: since efforts are concentrating towards
reducing the libmng footprint, isn't it possible to redirect some of these
efforts towards replacing the entire libpng with libmng, for PNG rendering? I
understood that libpng is older and more reliable -- which means that more
efforts should be concentrated around more libmng testing. What else would be
required?

I am not asking people to do extra things (which may look bad, considering that
I am not doing anything myself); I am only suggesting to spend the efforts in a
different direction.
I'll answer comment #148 in bug #204520.  Please continue the thread over there.
as for using libmng for png images, see bug 48893

Comment 151

16 years ago
------- Additional Comment #131 From Gervase Markham 2003-06-13 09:22 -------

   I am working with the imglib maintainers on defining a set of criteria that
   they want to be met in order to get MNG back in. As soon as they are agreed,
   I'll let everyone know what they are.

It has been two-and-a-half weeks and I've heard nothing on the maintainers'
(most of whom have e-mails ending in @netscape.com) demands for reinstating the
MNG format. However we have many contributors that could become MNG maintainers
and very good progress has already been made in reducing the file size. I
believe there is an effort underfoot to remove MNG without valid reason.
I have, as yet, had no reply from one of the imglib maintainers who needs to
sign off on the criteria under discussion.

Gerv

Comment 153

16 years ago
well, what about this guy:
http://www.cs.waikato.ac.nz/~singlis/

kinda cute, imo. what do you think about the software.  He mentioned scanners, i
am overly fond of scanners; so maybe i am too biased.

Comment 154

16 years ago
Which maintainer isn't replying? I find it ironic that part of the reason MNG
was removed by the imglib staff is because of the lack of an active maintainer,
when... well, you know.

Comment 155

16 years ago
ImageLib maintainers, according to
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

    Owner: jdunn@netscape.com;  QA contact: tpreston@netscape.com

ImageLib has maintainers.  The MNG part didn't.
I've checked a "slimmer libmng" in to libmng's CVS.  For details see
bug #204520 comment #56.  Hopefully this will provide sufficient information
to the powers-that-be to help them decide how much reduction is required.
Damian, skewer: the maintainer in question is Stuart Parmenter (pavlov), not one
of those you name.

Gerv
Depends on: 196670

Comment 158

16 years ago
I just looked over the recent developments here, and here is a summary. Please
correct me if I'm wrong.

* This bug has over 500 votes. It is by /far/ the most voted-on bug in Bugzilla,
ever.
* Glenn has been waiting on comment 21 in bug 204520 for a month and a half with
no response outside of a outrageous request from IRC. That is to say, nobody has
formally set a target size for libmng despite requests.
* The original complainer and the person who checked in this bug to the trunk
(tor@acm.org), who I suppose is the proper authority regarding comment 21, has
not commented in any of these bugs since early June AFAICT.

I would therefore believe that the original complaint is dead, and the want for
MNG support is very high, so there is no reason why libmng-1.0.6 should not be
checked into the trunk immediately when it is released.

Looking forward to the day when bug 195280 is marked WONTFIX.

Comment 159

16 years ago
Gerv: I wonder if pavlov will (wants to) stay a module owner in the
now-different situation (employer)...

Additionally, I believe we should have some better organization of module owner
issues - but I'll take that to npm.seamonkey
> Gerv: I wonder if pavlov will (wants to) stay a module owner in the
> now-different situation (employer)...

That's something you'll have to ask him. :-)

Gerv

Comment 161

16 years ago
Don't think I'm going anywhere.  Remember, I was working on Mozilla well before 
I started at Netscape ;)

Comment 162

16 years ago
And would you have the time and be so kind to answer some of the questions that
have been asked, regarding the validity of reasons behind removing MNG support,
and what would be required to re-instate it?

Eg. are 518 registered bugzilla voters an indication of more wide-spread use
than assumed? What reasonable size-reduction would be required to consider it a
useful addition to Mozilla rather than a bloat?
I'm still here, too.  I was working on Mosaic-2.4.1 (see changelog) before
Netscape had been heard of by the general populace, and before PNG/MNG were
invented.

Current situation with MNG reduction, on a particular platform
(FreeBSD/gcc-3.2.1) is about 179k:
  62k removal of redundant and unused functions in libmng,
  50k removal of unused functions in libpng,
  17k removal of 16-bit sample support in libmng, and about
  50k merging libmng and libimg2 to avoid storing two copies of the jpeg
library, as demonstrated by tor.
  IMHO that is enough.  How about putting MNG back on the trunk now?
  Additional 7k could be obtained by removing Delta-PNG support but I don't
recommend that, and about 13k by removing JNG support but I don't recomend that
either.

Comment 164

16 years ago
And as usual, we get no response...

Stuart,

is it just me and Glenn, or are you this plain rude to everyone with a fleeting
interest in PNG/MNG/JNG? It's not like we're asking you to solve the mysteries
of the universe or something...

Comment 165

16 years ago
"Stuart Parmenter" pavlov@pavlov.net was the strongest supporter of removing MNG
without justification. I don't think his opinion is valid in this issue.

Comment 166

16 years ago
FYI: If pavlov could provide some definite requirements for his supporting MNG's
return, and the full imagelib crew agrees with those requirements, I would be
more inclined to respect his opinion on this matter. But he personally backed
and approved the removal of MNG without a single word about why, and now that
he's the only person who needs to say anything, he's filibustering the whole
operation and still has provided NO REASON why he would want MNG removed. This
is an insult to thousands of Mozilla users and a direct insult to 520 Bugzilla
users who are voting for this bug. Things need to change here.

Comment 167

16 years ago
What's this, Bugzilla invasion of the trolls?

Gerard, ever thought that maybe Stuart doesn't spend his time 24/7 in front of
the computer, trying to solve what *you* think is an important issue?

Skewer: Find a new place to troll. Thanks!

Comment 168

16 years ago
trusted2mozilla.org@slater.ch please take your bugspam elsewhere, thanks

Comment 169

16 years ago
Mark:  Umm... since you weren't paying attention, Stuart has neglected to give a
response for over a month now.  It doesn't require being on a computer 24/7 to
say something in that time.  Also, he responded to the inquiry as to whether he
would continue to be the module owner just the other day, without saying one
thing about requirements for reimplentation of MNG.  So the impatience is quite
justified.
skewer: pavlov is the imglib module owner (last time I looked), so his opinion
is very much valid.

Mark: gerard (with Greg) is one of the people who has been working hard on MNG
over the past few weeks, so his frustration is perfectly understandable.

Can we calm down a bit here, please?

Gerv
For those who have misinterpreted my statement "IMHO that is enough", that means
in my humble opinion it is enough to warrant checking MNG back into the trunk,
not that I intend to quit working on it.  I am committed to continuing to reduce
the size of libimg/libmng unless I find out for sure that it is a fruitless
exercise.

Comment 172

16 years ago
   skewer: pavlov is the imglib module owner (last time I looked), so his opinion
   is very much valid.

Gerv: And Bush is the U.S. President. That doesn't mean he knows what he's doing
or belongs there. What argument is there not to remove GIF because of the Unisys
patent issues or because there is a viable alternative available (PNG, MNG)? In
fact, why not remove XML, how often is it you run into a webpage that uses XML?

Comment 173

16 years ago
Skewer: Let's see how did you put it . . oh yea "please take your political-
spam somewhere else please, thanks."

Comment 174

16 years ago
skewer: Your political commentary was completely off-base.
However in light of the work done and improvements made of late, it does seem
like someone very much doesn't want to concede that they might have made a
mistake when deciding to remove libmng indefinitely.

Comment 175

16 years ago
I lost my patience for a moment and I apologize. Even if it's pretty obvious
why. I certainly didn't want to star a flamewar, so let's all stay civilized and
work towards a solution. Ranting doesn't work! And Mark, I *don't* think it's
important, in fact, I couldn't give a hoots **** at the moment whether MNG comes
back or not. There are a lot more interesting things happening in my life right
now. But don't read that to mean that I'm not interested. libmng has been my pet
project for 4 years and will remain so for some time to come, and I'll work with
anyone that *works* with me!!!

Just to recap for those that do not want to go through the entire backlog.
Here's the status on the original reasoning behind the removal:

>  * 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

From bug 204520 comment 60:
  MOZILLA_1_4_BRANCH libmng:         189K
  tip libmng-devel/mozlibmngconf.h:  112K

That's a 77K (40%) size-reduction in the bare decoder. Looks to me like Glenn
has already done an incredible job towards reducing the size. Also 50K were
saved from the libpng implementation, another 50K could be saved by removing the
duplicate JPEG code. Also the optimized MNG throbbers for Firebird are a fair
bit smaller than their GIF-makeovers (bug 195280 comment 100).

And we still have more ideas on how to decrease the size of libmng further. But
neither of us is going to spend a lot of time working in the dark. If pav can be
se kind to answer our question on what size-reduction is required, at least
we'll know what we're working against. And I mean a real number, not some off
the top of the head figure akin to impossibility. A valiant module-owner
wouldn't hesitate to answer such simple mathematics. I don't mind if there are
more personal reasons behind keeping MNG out of the tree, but at least come out
and say so. I've been down such paths myself a couple of times, but believe me,
the ostrich-way really doesn't pay off.

>  * 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.

There is still no active maintainer. The most obvious person at this point
(Glenn) has been turned down. The fact remains that the new maintainer wouldn't
actually need much knowledge of the MNG library itself, since he/she will have
Glenn and me for the full 200% behind him/her to solve any issues relating to
the MNG decoder. Maintenance would therefor be more of an administrative task
then real grunt-work. If we would have had a bit of co-operation from the
module-owner, I would have spent a lot more effort in squashing the currently
outstanding bugs against MNG.

>  * 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 not w3c recommended.

As many people have stated this isn't much of an argument. Have a look at bug
195280 comment 100 and see if MNG isn't a tat superior to animated-GIF. And
AFAIK themes can't use flash. Other arguments against this point are that MNG is
an open standard, not proprietary or flee-ridden with patents, it's a lot more
sophisticated than simple 8-bit paletted image-streams, can achieve better
compression than GIF, and can be run transparently against the background. You
can only achieve that with Flash if you design the whole page in Flash, which
makes it rather impossible to maintain.

>  * the formats are little used in the wild.
  
500+ registered bugzilla voters think not. The Firebird crew and many other
theme-authors didn't think so. And what kind of thorough investigation has been
done to support this point? MNG usage is growing thanks to Mozilla! Let's keep
it that way. You've got a great product. And as many people stated before,
Mozilla is an open-source platform that gives new emerging technologies a
foothold to gain the status they deserve. *Mozilla* makes the difference, not IE!!!

Gerard

Comment 176

16 years ago
I don't think anyone caught my point, they were too busy accusing me of trolling
or spamming, so I'll put it simply:

The reason this bug, bug 18574, is not currently FIXED, is because
<pavlov@netscape.com> (anyone wonder why I prefer to refer to THAT e-mail?) and
only pavlov is not providing the criteria which would allow MNG to be checked
back in. Since he is the imglib owner he has the authority to stop MNG from
being included in Mozilla for absolutely no reason at all. That's exactly what
is happening--no reason at all is being given for its current exclusion from
Mozilla. The size has been reduced more than it needed to be (the additional
size of a typical Flash or GIF animation compared to an optimized MNG is more
than the difference in the code made by removing the libmng library). Lack of
widespread usage might be a valid reason to remove something like this from IE,
but this is Mozilla, and there are plenty of little-used standards that are
being included because they're good, not because they're popular; for example,
CSS3. W3C recommendation isn't a valid reason, because bug 3744 is based on the
"GNKSA" guidelines some kid made up. Just about any reason for stopping MNG can
also by stymied by the fact that we even include MARQUEE support in Mozilla.
Overall this MNG removal thing is something that never should have happened. Am
I right?

Comment 177

16 years ago
This is a question based on my understanding of the processes put in place by
the mozilla organization, and as such, may be based entirely on a misunderstanding.

But as I understood it, all module owners are answerable to drivers, and if a
particular module owner is not doing an adequate job, the drivers can
investigate the issue and come up with a solution including anything from "allow
this bug to be checked in, regardless of what the owner says" up to and
including revoking the person's ownership position.

To be clear: I am NOT suggesting that pavlov should be removed from imglib
ownership. However, I *do* think that he has failed to carry out his duty as
module ownership in this case: that duty would certainly include providing a
timely response to an entirely reasonable question like this.

As such, doesn't the normal mozilla process say that the appropriate action now
would be to contact drivers?

Gerv, as the person who's taken the lead on bringing this to a diplomatic
solution, what's your take on the current situation? Do you feel that the delay
in getting a response is still reasonable? If so, how much longer until it
becomes unreasonable, and am I right about the correct action to take in that
case? (I'm not trying to propose an ultimatum or anything like that, but *some*
kind of limit to how long this bug is going to sit in limbo would be appreciated
by everyone involved, I think)
> Gerv, as the person who's taken the lead on bringing this to a diplomatic
> solution, what's your take on the current situation? 

Your understanding of mozilla.org process is correct. It is up to individuals to
decide when and if to escalate a particular issue to drivers, and if they are
the most appropriate person to escalate that issue.

Those who are considering this course of action may do well to contact Gerard or
Greg, as they are the people currently hacking on MNG. 

Gerv

Comment 179

16 years ago
Gerv,

It's Glenn and me, but mostly Glenn doing the hacking. Greg's our punchball in
the back. We'll be getting in touch with drivers some time this week. Just
deciding who's doing the writing...
Sorry, guys - all your names begin with G, and I get confused :-)

Gerv
> there are plenty of little-used standards that are being included because
> they're good, not because they're popular; for example, CSS3

HMMMPPPFFFF.....

Comment 182

16 years ago
I know, this bug gets spammed out to over half a thousand people now, but I just
wanted to link to this little project:
http://sgs1.brinkster.net/gserver/

I got it off of this MNG site:
http://www.doc.cs.univ-paris8.fr/mirrors/mng/mngaped.html

What I find interesting about something like this is it is a quick easy
browser-based alternative to VNC (yes, there are VNC Java Applets, but
nonetheless).  I recommended it to my boss, who has been looking for something
like this.  If he starts using it, I imagine he'll be either looking to install
Netscape/Mozilla on remote computers, or the IE MNG plugin.

Even more then a website, a browser based application they depend on is
something people might go out of their way to install Mozilla for.  Especially
if they were used to using it for this reason on their home/work computers.  Of
course, if MNG becomes a plugin, then people would probably just use the IE
plugin.  No difference, after all.  Similar reasoning applies to intranets.  
Indifferently supported web standards often get a toe-hold there as well.

Just one more reason along with MNG in the classroom (Mozilla as default install
on a college network is another source of evangelism), and MNG throbbers, as
well as the amazing difference between a 20k translucent JNG and the 200k PNG
that would be needed for same effect.

Ok.  My one and only bug post on the subject :)

Comment 183

16 years ago
pavlov:
I wanted to watch my favorite pr0n clip with current Mozilla, but I failed to
see it. I'm confused now, as as http://libpr0n.com/faq.html says it should
support it's MNG format.
Either your webpage is wrong, or Mozilla doesn't qualify for a good pr0n
browser, as animated goatpr0n comes best in MNG format.
Pavlov had nothing to do with that web site.  See bug#66984 comment#6.

Comment 185

16 years ago
I tried to install the mng extension from the firebird extension website and it
didn't work (I verified this by trying the bugzilla testcase on the top of this
site http://bugzilla.mozilla.org/attachment.cgi?id=124879&action=view ).

The installation failed with 0.6.1 official (=final) build and the latest
nightlies {current one is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.5b) Gecko/20030731 Mozilla Firebird/0.6.1}.

having restarted the first time after the extension installation, firebird gave
me an error : "the application couldn't be started because mozz.dll couldn't be
found".

firebird started anyway and after the next restart the error msg was gone, but
mng animations didn't display.

so there isn't native mng support anymore nor a working extension.

see: http://forums.mozillazine.org/viewtopic.php?p=133923#133923
I hate to reply with this many cc's, but leaving the previous comment without a
response helps nothing.

bernd, the extension in question has issues on Firebird Windows, but works on
Seamonkey Windows and both products under Linux (apparently), at least based on
that and other threads.  mozz.dll does not exist under Firebird, so the
extension isn't really compatible.  Maybe the extension author should update it,
who knows whether he's interested still.  If MNG is that important in the short
term, use Mozilla Navigator with the extension or use Linux.
I opened bug #214737 for discussion of the MNG XPI problem.
Whiteboard: DO NOT COMMENT UNTIL GERV GETS BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG → DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG

Comment 188

16 years ago
Updating dependancy tree, removing duplicates and putting bugs they are
duplicated to.
Blocks: 156450
No longer blocks: 198591
Depends on: 41333

Comment 189

16 years ago
I'd wanted to nominate this bug as a blocker for version 1.5, just because I
can't think of a normal (non-alpha, non-beta) version of Mozilla without MNG
support. But because this is not possible (yet) I'd nominate this as an 1.5beta
blocker.

One of the main reasons of the removal of the support was the size of the
decoder, in the other comments of this bug is alreday stated that there can be
more size/footprint winnings when converting the (animated) GIF's in the chrome
to MNG. So if we are concerned about the reduction of the size we should do that
(too).

BTW: There is no need in blocking 1.4.x, because the branch for 1.4 was cut
before MNG support was removed from Mozilla.
Flags: blocking1.5b+

Updated

16 years ago
Flags: blocking1.5b+

Comment 190

16 years ago
Maybe the person who removed the "blocking1.5b" flag could leave a comment to
explain why they did so?
Only drivers should set blocking+ flags. If you wish to nominate a bug for
blocking status, set the blocking? flag.

Comment 192

16 years ago
I'll take the leap here and set that.
Flags: blocking1.5b?
Re: comment #186 and comment #187; the MNG extension is working now with
Firebird.  See http://quicktools.mozdev.org/mngsupport/ which is based on
the attachment #125114 [details], above, plus mozz.dll and some Windows registration settings.

Updated

16 years ago
Flags: blocking1.5b?
Flags: blocking1.5b-
Flags: blocking1.4.x-

Comment 194

16 years ago
Asa, could you please explain why you removed blocking1.5b for this bug when it
is the most voted-on bug in all Bugzilla and can be easily fixed?

Comment 195

16 years ago
referring to #193:

sorry glenn, 
this new xpi didn't fix my problem either. 
steps I did:
1) installed the "complete MNG Support for FireBird (mng-windows-fb.xpi)
extension package"
2) restarted firebird
3) tried testcases -> all testcases failed
4) checked "extensions" in "options" -> no extension was installed
5) executed mng.reg manually as instructed on the site you mentioned
6) made sure mozz.dll was in the firebird folder
7) installed "MNG Decoder for Windows (92 KB Download)" from
http://stud4.tuwien.ac.at/~e0225227/ (the "original Extension page")
8) tried testcases -> all testcases failed

Conclusion: still no mng firebird support on windows. 

tried with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030808 Mozilla
Firebird/0.6.1+
Please continue discussion of XPI in MozillaZine->Firebird forum:
http://forums.mozillazine.org/viewtopic.php?p=145184#145184
Since I know Asa doesn't get bugmail for most/all changes: #194, look at the
link in comment 114 as to why votes don't always equal action.

And just to clarify for those who tried adding the blocking flag: The
requirements have been laid out in bug 204520, and those are what is needed for
MNG to be added and this bug fixed.  Until those goals are met or modified,
drivers have made it clear that this will not be added back to the trunk.  As a
result, requests to block any release will be denied since drivers already
decided it could be removed until the goals are met.

Comment 198

16 years ago
Re: #194:
"Asa, could you please explain why you removed blocking1.5b for this bug when it
is the most voted-on bug in all Bugzilla and can be easily fixed?"

Several reason:
This bug is not _ready_ to be fixed as as set of specs is still beign drawn up
by module owners and drivers. This bug in now way is a sudden regression, or
otherwise urgent in the scope of the 1.5b release and does not even rise to the
level of rendering sites incorrectly. Also, did you not see this?
Status Whiteboard: DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS
(COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG

It's pretty clear this bug is not close to being resolved yet.
Whiteboard: DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG → DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG. YES, THIS MEANS YOU TOO!

Comment 199

16 years ago
referring to #195:

a complete dump of my former profile let me install the xpi. 
thanks for all those messing with the mng and the mng-xpi creation.
:)
I have received word from drivers.  They invite MNG support to be put back in
the image library as a configurable option that is turned off in default
mozilla.org-produced builds (Seamonkey, Firebird,  Thunderbird).

They are interested in having only MNG-VLC supported as a configurable 
that does not entail all the footprint of full MNG, and would support 
such a subset being turned on in mozilla.org-produced builds and made 
part of the "typical" GRE configuration that Mozilla.org brands and promotes
(aside: we see the need for "minimal", "typical", and "all" GREs, with 
"typical" being widely deployed on desktop machines).
Whiteboard: DO NOT COMMENT UNTIL DRIVERS GET BACK TO US REGARDING STATUS (COMMENT #131). IF YOU HAVE TECHNICAL ISSUES, SEE BUG 204520 OR FILE A NEW BUG. YES, THIS MEANS YOU TOO! → PLEASE USE BUG #204520 TO COMMENT ON TECHNICAL ISSUES.

Comment 201

16 years ago
(drivers invite MNG support to be put back in 
the image library as a configurable option that is turned off in default) 
 
And we all know that that will be useless. While telling users to use Mozilla 
for certain content might be feasable, telling them to choose special 
configuration options clearly is not. Also all current users of Mozilla will 
have to mess around and it won't work out of the box. People will forget it 
when upgrading. 
 
 
This quote from Glenn in bug #208607 shows IMO how ridicoulous and frustrating 
the whole situation already is: 
 
"My patch for reducing 
libpng another 5-10k in addition to 50k already saved by me to make room 
for MNG support has been lingering in bug #208607 for a couple weeks 
without any response.  I have also reduced my own copy of the jpeg library 
significantly, too, but why bother?" 
 
IMO this all is not about memory footprint, but only about pride, power and 
control. Which is all very sad. 
 
 

Comment 202

16 years ago
I don't wish to lay blame or attack anyone - I'd just like a clarification of
the state of affairs without loads of Moz. Dev. TLAs:

Is it now true that the main reason for not [re]including MNG as default is it's
footprint?  I seem to recall reading above that more footprint is /saved/ by
converting the default chrome's animated GIFs to MNGs that is taklen up by it's
inclusion in the library - an overall footprint /decrease/ by including it.  Am
I right?

Also, I'm not quite sure I understand the mechanism by which MNG will/will not
be present in a moz under the seeming current plan.  Will it need a special
build, or will it 'be there' in the default build but not downloaded by default
unless some installer tickbox is set?  If it's not 'there', what happens if a
MNG is found whilst browsing - will there be an automated 'plugin dialogue'
offering to make it work, or will it just not display?

Comment 203

16 years ago
to Neil Bird -> let me explain the mechanism: not being built by default, will
not be supported, you will have to find somewhere a Mozilla build with support
enabled

Comment 204

16 years ago
So, essentially, the current status quo is preserved. Is anyone surprised?

Comment 205

16 years ago
Drivers supports the reinclusion of MNG-VLC in mozilla.org builds, via it being
"on" for "typical" GRE Builds.

What this means is, the full MNG spec will not be compiled by default (but will
be available as an option), but they MNG-VLC *will* be compiled by default,
*and* available for install in all but the "Minimal" GRE configuration.

Before anyone accuses drivers of maintaining the status quo, read above. In
essence drivers have approved the reinsertion of a signifigant portion of MNG
into the tree.

Comment 206

16 years ago
Is that a tentative "yippee" then?  What's "VLC"?

Comment 207

16 years ago
Could you please explain the difference between "full" MNG and MNG-VLC? Thank you.

Comment 208

16 years ago
"Limiting the feature set in a widely-deployed WWW browser to anything less than
MNG with 8-bit JNG support would be highly inappropriate." - (MNG-VLC Format
Version 1.0) PNG Development Group
[http://www.libpng.org/pub/mng/spec/mng-vlc-1.0-20010209-pdg.pdf] Page 18.

If that statement means "full MNG", it might be worth reconsidering Mozilla's
position.
It is status quo from the perspective of webmasters and of those who download
official binaries.

From developers perspective, MNG support (slightly crippled) will be back on
trunk and can be enabled with a simple "--with-mng" or something.

Everyone will still have the option of installing a fully MNG-supporting XPI.

From the MNG evangelist's perspective it's not too good because it stifles
potential MNG usage on web pages (although of course IE is already doing that
for us) and in skins/chrome where we were actually making some inroads.

"VLC" is a "very low complexity" version of MNG that is little more than
a stream of PNG files in a MHDR/MEND wrapper.  It was developed in response
to people who wanted a very simple MNG for handling multiple-page FAX files
and the line, and wasn't intended to be a browser format.

Comment 210

16 years ago
For more information about MNG-VLC, see:
  http://www.libpng.org/pub/mng/spec/mng-vlc.html
Short summary from that page:
  MNG-VLC is "A very-low-complexity subset of MNG that does not use stored
  objects, variable framing rates, location of images at positions other than
  (0,0), or other complex features. The "simplicity profile" in the MHDR chunk
  must meet certain requirements [...]"

Comment 211

16 years ago
It should be noted that MNG-VLC *cannot* replace most animated GIFs, due to the
limitations of frame rate and offsets in MNG-VLC.  The only formats that could
replace animated GIFs are MNG-VLC or full MNG.

Comment 212

16 years ago
In other words, not very useful as an animated GIF replacement and prohibitive
for development and uptake of MNG-based websites.  The extension option really
isn't viable for the common user, unless it's maintained by mozilla.org and it
is automatically downloaded and installed the first time a user comes across a
site with MNG/JNG on it.  I don't know of any infrastructure currently available
to do that.
All other debate aside, it seems to me that this new route is going to cause
MORE maintenance issues rather than less due to all the extra ifdefs and
compile-time options that will need to be included.  This would likely increase
the source code size, even if it slightly lessens the binary size.  I hardly see
how this is logical when looking at the original reasons for removing MNG.

Comment 213

16 years ago
Sorry for the spam...  In my previous comment, I wanted to write "MNG-LC" instead
of "MNG-VLC" for replacing animated GIFs.  For more information, see:
  http://www.libpng.org/pub/mng/spec/mng-lc.html
Still, I am glad that the drivers are allowing at least one part of MNG to come
back into Mozilla, even if it is crippled and may cause more problems than it
solves.

Comment 214

16 years ago
To sum it all up again, what actually *does* speak against full MNG/JNG support
in Mozilla? The only reasons given
(http://bugzilla.mozilla.org/show_bug.cgi?id=195280) seem to be that

1. The MNG decoder is too big
2. Mozilla integration is "rather rough", whatever that means
3. GIF, Flash and (possibly in the future) SVG cover the same featureset
4. The formats aren't used (much)
5. The formats are not w3c recommended

Reason 2 seems like a non-argument to me ("rather rough" integration means that
it should be worked on, not ripped out). 

Reason 3 is invalid since GIF is patent-covered (and the patent is still in
effect in many countries, like, for example, Canada).

Reason 4 is also a non-argument; we might just as well remove XHTML or MathML
support from Mozilla for the same reason.

Reason 5 is another non-argument; the w3c does not officially recommend GIF,
either, as far as I know.

That leaves us with reason 1: codesize. I don't think that this is a a real
issue myself, but I can understand that others are worried about code bloat in
general, download times (especially for analog modem and isdn users) etc. The
solution I'd propose would be to either make available different builds of
Mozilla with different featuresets, or, better, to make support for MNG and
other formats configurable at install time, so people using the Net Installer
wouldn't have to download what they need in the first place. MNG support should
also be an option that is selected by default; the relatively small increase in
code size (given as 240k on Linux, 170k on Windows on bug 195280) does not
justify turning it off by default given the relative importance of MNG as a free
and unencumbered alternative to GIF, Flash etc.

Thoughts?

Comment 215

16 years ago
Sorry for spamming here, just one small comment:
I consider MNG coming back into the trunk, even if only enabled via a compile
option, being a major step into the right direction.
This way, work can be done to prove it e.g. as stable as libpng and being good
enough to eventually take over rendering of PNGs. Such a movement could possible
lead it back into default builds as well.
Having MNG-VLC in default build would be a first step as well, as we probably
can move up to MNG-LC or more later on.
And Mozilla-based products, which may need full MNG, can include it by default,
as well as any custom Mozilla distribution (perhaps the SVG-enabled builds as well).

As I said, it's a first step, and it's a good sign to see at least that happen.

Comment 216

16 years ago
> 1. The MNG decoder is too big

A lot of things are too big and less important than MNG.

> 2. Mozilla integration is "rather rough", whatever that means

This is obviously not the reason, otherwise they wouldn't agree to introducing
MNG-VLC

3. GIF, Flash and (possibly in the future) SVG cover the same featureset

GIF is patent encumbered and technologically limited, 
Flash may be the status-quo but doesn't work well outside of Windows, MacOS, and
Linux-x86. Even the Linux-x86 port isn't that great.
SVG - great thing, love to see it happen, but can SVG and MNG not 'get along'?

> 4. The formats aren't used (much)

Because none of the browsers support it!  All of the webbrowsers are looking
around saying, "I'll support MNG when everyone on the web is using it.", but
nobody will use it until the browsers support it. The browsers won't support it
until everyone is using it or all the other browsers support it.  It is possible
that once Mozilla implements it, the other browsers may follow.

> 5. The formats are not w3c recommended

I agree that SVG is great and should also be implemented, but a lot of things
aren't w3c recommended.  

Now, the arguments that GIF isn't w3c recommended but is supported shouldn't be
used as an argument because GIF has legacy behind it.  JPG also has legacy
behind it.  They are the status-quo, you can't have a leading browser without
GIF or JPG support.

Hopefully one day SVG and MNG will be part of the status-quo and it will be
ludicrous to have a browser that doesn't support them without being deemed a
'text-only' browser.

SVG and MNG will NEVER become the status-quo if they are never implemented into
browser simply because someone is not willing to take a risk on new technology.
  I understand, it is a risk; but it can be undone.  I also understand that not
every proposed technology can or should be implemented.  Somehow PNG has managed
to rise, look at how popular it has become, it is used nearly everywhere now.  3
years ago I sent someone a PNG image and they didn't know what to do with it,
now they are as familiar with PNG as they are with JPG.  I feel that MNG will be
the replacement for the animated GIF as we know it today and will be the safe
and easily used medium for those not needing something as dynamic as SVG or
something as static as PNG.

I applaud the agreement that MNG-VLC should be included, but I feel that it is
too limiting to offer any advantage to GIF, especially with the outweighing
disadvantage of backwards compatability faced by web designers.

In conclusion, MNG should be included with at least as many features as that of
GIF as to make the format a viable option for web designers, to help spread it's
usage, and finally to convience other browsers that yes, it can and should be done.

If MNG is not fully implemented in Mozilla, then every effort should, no.. MUST,
be made to including and optimizing SVG.

Comment 217

16 years ago
>Is it now true that the main reason for not [re]including MNG as default is 
it's
>footprint?  I seem to recall reading above that more footprint is /saved/ by
>converting the default chrome's animated GIFs to MNGs that is taklen up by it's
>inclusion in the library - an overall footprint /decrease/ by including it.  Am
>I right?

Could one of you 'in-charge' care to answer this for me? If that statement is 
true, why is the default chrome still using GIF's? 

Comment 218

16 years ago
Would anyone be interested in maintaining an alternative Mozilla which will NOT
be supported by mozilla.org, that has full, real MNG built? Mozilla.org has
indicated that it is not interested in restoring MNG (essentially this bug is
WONTFIX). Right out of the box such a project has a guaranteed 565 users, and
probably quite a few more once word gets out that mozilla.org has closed its
doors on the MNG format. (Once the "fixed" Mozilla starts to take over
Mozilla.org's market share they may change their minds about this.)

Also, the maintainers of the LibMNG homepage need to be notified that Mozilla
does not support MNG or JNG anymore per administrative order. The contact
address I found was newt at pobox.com.

Comment 219

16 years ago
Skewer --> If it does turn out that the drivers are all that stupid, I will be 
very glad to withdraw support for the monolithic Mozilla Foundation and 
petition Debian to change its default browser to your branch. 
 
(Written using Konqueror) 
right, insulting and threatening people is always a good idea if you want people
to do something you want

Comment 221

16 years ago
Well, Chris, there was an "if" -- I don't think Ashi or Skewer would directly
just say or think something along the lines that drivers are full of it; I don't
think these comments were meant to be outright offensive.  It's simply that ever
since this stupid issue started, those who decided to remove MNG never even
bothered to tell the real reasons.  No matter how nice or how unnice the people
on this "forum" were.

If anything I find it a bad thing not to communicate with the users.  And no,
those initial "reasons" were not acceptable, most of them having been disproven
by either simple logic, or by the results of the work of the G group (Glenn,
Gerv, and whoever else starting with a G, sorry about my name memory, Greg
p'haps?) and Tor, re: size.

It would be high time that the one who actually started the whole thing
(pavlov@pavlov.net IIRC) came up with something decent of a reason, because we
won't eat this (as it can also be seen).  Not to mention his attitude, that is
nothing but selfish, and I'm sorry to see something like that in this community.

I'm glad that a minimal version is considered to be put back in the trunk, but I
still don't see any decent reason about why just a rather neutered version of
MNG can be directly supported.  What /is/ this obsession with closed and/or
patented standards?

Thanks for reading,
R.

Comment 222

16 years ago
Ashi, Eric, Skewer, Henrik:
You're all suggesting that either drivers, tor or pavlov - or all of them - are
stupid, braindead or dumb. This is simply not the case. pavlov and tor are
genious programmers, and drivers are clever people who are overseeing the project.
The initial primary reason for kicking out MNG was that there was no maintainer
of the code, it seems. This problem looks solved currently, and there's good
reason to re-include the code in the tree and if it stays well-maintained,
re-include it into the default builds gadually over time.
The second problem, code-size was heavily work-on by another genious, who fits
well as the maintainer of the code, and I think the whole issue would work out
after some time.
drivers@mozilla.org are _not at all_ stupid, as they tried to calm down the
discussion and proposed a way that should be acceptable for all sides of the
discussion, though it is a compromise. This is what diplomatic and political
processes are all about in real life, and in such a project as well. It's not
the ideal solution for all parties, but it's a base to work upon. Please don't
poison that try to calm down the conflict.
I'm just a simple user, and yes, I'm interested in having MNG as well, as I see
quite a few pros, but it's just the wrong way to tell people they're stupid just
because they might have some personal obligation.

(sorry to spam a bunch of you people that already know all of that - this
comment shouldn't be needed, as lots of others that keep the flames burning.
Well, this is OSS though, and flames seem to be a part of OSS spirit after all...)

Comment 223

16 years ago
If it didn't show, I'd like to emphasise I don't think they're idiots.  I'd like
to emphasise something else too, though: pavlov never came back to tell us any
decent excuses, as far as I know, having been reading this bug for a couple
months now.  I have definitely not questioned their programming abilities, nor
have Skewer and Ashi questioned that; I personally will accept that both Tor and
Pavlov are good programmers.

I am questioning the general attitude of Pavlov, though, and the elongated
silence of drivers --- that though with the re-inclusion of MNG-VLC has broken.

re: Reason For Kicking MNG.  I recall pavlov and tor coming to tell they have no
mng maintainer.  After some posts, a couple of the G's mentioned they could try
to find time soon for it, and would gladly take over maintenance of MNG.  Some
posts later pavlov announces something along the lines "ok, I have taken out MNG
from the trunk." and poof he's gone, seemingly(!) without having considered the
G's.  After that, I recall Gerv and Glenn and Tor trying and succeeding to
reduce the size of the libs which was perhaps pavlov's most valid point among
the invalid ones like "people have no interest in using it" or something that silly.

I am definitely happy that gradual re-inclusion is considered, but what the
people here keep whining about is com-mu-ni-ca-tion.  We just don't get real
feedback and good reasoning.  Is it too much to ask for someone to share us the
real requirements?  Been asked for for a good while, I'd like to remind.

I say again, I don't think the drivers are stupid, they just took helluva much
to react at all (or so it seems from reading this bug), and even then we didn't
get to know much (or are my eyes closed?).

That's all I wanted to add,
R.

PS: yes, things have been repeating all over and over, I'd say we all know the
pros and cons... which is why I'm so surprised on pavlov's obsession with
patented standards :P
Drivers *did* reply, if only via a private message to me (comment #200).
I am working on a cut-down version of libmng that only supports MNG-VLC,
and should have that checked in to the libmng CVS today.  Since the cutting-down
is via #ifdef macros, anyone will be able make a partly- or fully-MNG-supporting
"unofficial" build of Mozilla or FireBird.
well, stupid was: 
- to remove the code after somebody said, he will work on it 
- creating arguments, like "nobody uses it", "code to big" or "not W3C recommened", which you 
could also use to stop the whole project and write an IE clone 
- to say "I don't care about votes" 
- not to answer on mails for a long time 
- to show not having understood the possibilities of MNG compared to GIF or Flash 
- to set unrealistic readd requirements 
- breaking compatibility with older Mozillas at all 
- to readd a useless MNG ripoff (called MNG-VLC) 
- to say "everything went it's normal way". 
If it's the normal way not to care about the communities oppinion (and the community are not the 
users, the community are the users, who say, what they think about something!), it would be 
better to stop the whole game. So I wouldn't say pavlov is stupid, but he made many things wrong 
and behaved like a dictator. 

Comment 226

16 years ago
As far as I'm concerned, MNG-VLC is the same as no MNG at all. It is useless 
as an animated GIF replacement and useless as a form of animated JPEGs. Adding 
in only MNG-VLC would therefore make Mozilla's MNG support exactly what 
drivers and pavlov claim it to be-- useless bloat! 

Comment 227

16 years ago
Why would you not want to put this into Mozilla?  GIF has those stupid patent
issues.  This format does not.  Also, and if the library is a little bigger who
cares?  Are you loading ALL the libraries into memory at once.  I seriously
doubt it.  So, this means it can be left in and called on when it is needed. 
Just because W3C doesn't list it, does that mean it should be left out?  I think
not, since the whole key of their site is supposidly to encourage NEW ideas. 
MNG would replace animated GIF files without a doubt with its smaller size when
compared to GIFS.

QUOTE:
>  * 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

Come on.  166.3K in size.  That's not big compated to other DLL files that I've
seen.  The feature warrants the space.  Anyway, if that size were an issue, why
would people download software like Shockwave when it takes up a ton more space
than even this library file itself, or even items like RealVideo?  Why?  Because
they want the feature available.

I feel that this format would replace GIF just as JPG replaced BMP files on web
sites.
I've posted a patch to downgrade libmng to a MNG-VLC-supporting version
only, in bug #204520.  When applied to mozilla-1.4, it creates a static
libmozmng.a with "size -t" about 51k and libimgmng.so whose "size" is 77.5k.

Comment 229

16 years ago
Perhaps we could put in support for compiling Mozilla with MNG-LC as well. It
could be turned off by default, and it would give us another option for
negotiating MNG support with the Drivers.

Comment 230

16 years ago
Glenn has already added such support.  See the bug listed in Whiteboard Status.

Comment 231

16 years ago
   Yeah, I see it for Comments #78 and #80 in Bug 204520. There are three
config flags called MNG_BUILD_VLC, MNG_BUILD_LC, and MNG_BUILD_FULL_MNG. I like
that MNG_BUILD_LC includes a few non-MNG-LC goodies like JNG. MNG-LC + JNG
support should be optimal if the size is low enough.

   Ideally, I'd like to see Mozilla support MNG_BUILD_VLC for the "minimal"
install and MNG_BUILD_LC for "typical" and MNG_BUILD_FULL_MNG for "full".

Comment 232

16 years ago
"Everyone will still have the option of installing a fully
MNG-supporting XPI."

Will Mozilla.org provide such a fully MNG-supporting XPI for the
suite and for Firebird?


"5. The formats are not w3c recommended"

I'd guess that MNG, based on W3C-recommended PNG, is a lot
closer to being W3C-recommended in spirit than GIF is.


"to make support for MNG and other formats configurable at install
time, so people using the Net Installer wouldn't have to download
what they need in the first place."

I second this once MNG-VLC integration with Mozilla becomes stable.


"more footprint is /saved/ by converting the default chrome's
animated GIFs to MNGs that is taklen up by it's inclusion in
the library"

I'd guess that drivers are not counting a compensating reduction in
Mozilla browser chrome footprint because they want to reduce the
footprint for embedding, where Mozilla browser chrome is typically
not built.


"What /is/ this obsession with closed and/or patented standards?"

I suppose most of us already know this, but a freely
redistributable computer program such as the Mozilla browser
cannot implement any patented process unless the author can
secure a worldwide, perpetual, fully-paid-up license for such
process.  The only way to do this if the patent holder is
unwilling to sell such a license is to acquire a controlling
interest in the patent holder, and I don't think even AOL Time
Warner (Mozilla.org's former parent) is rich enough for that.


-- My view on the issue --

I understand the compromise that the drivers are making.
Part of it may have something to do with the difficulty
of reviewing and super-reviewing a huge chunk of new code
and the difficulty of getting enough tester coverage.

I'd support putting MNG back into the trunk with only MNG-VLC
enabled in official browser and suite builds, letting testers
shake the obvious problems out, and then filing separate bugs
to add MNG-LC and JNG to official browser and suite builds.
Get MNG-VLC in, get it tested, get it stable, then go from there.
> I understand the compromise that the drivers are making.
> Part of it may have something to do with the difficulty
> of reviewing and super-reviewing a huge chunk of new code

What new code?  We are talking about putting back on the trunk code
that is in Mozilla 1.0 through 1.4 and was already subject to 3 years of
review and super-review.  Only thing is now it's been pared down to
remove unused or redundant code, some rarely used features, and some
interesting features.

We are not asking for a new feature, but to undo a regression that took
place in version 1.5.  Drivers agreed to undo it, partly, and to allow
builders to undo it fully via a configuration option.  Drivers did not
make either of these concessions contingent upon any particular filesize
achievement (comment #200).

Comment 234

16 years ago
MNG support being partially restored in the form of MNG-VLC is better than
having no MNG support at all IMO, but I'd still like to ask one question:

What is the reason that drivers@ don't want to have / allow a full
implementation of the MNG standard in mozilla.org builds that is enabled by
default? 

I don't mean to bash drivers, but I simply don't understand what's actually to
be said against doing that. There is much to be gained by (re-)adding MNG
support, and I cannot think of anything that could be lost, so why isn't it
done, or even considered by drivers?

Comment 235

16 years ago
  You're all suggesting that either drivers, tor or pavlov - or all of them - are
  stupid, braindead or dumb. This is simply not the case. pavlov and tor are
  genious [sic] programmers, and drivers are clever people who are overseeing
  the project.

Answer this for me -- MNG was working perfectly fine before it was removed, with
very minor exceptions. No work was necessary to get MNG to work right, and I am
not aware of any bugs that were caused by its presence. In Bugzilla terms, isn't
that known as a regression?
> What is the reason that drivers@ don't want to have / allow a full
> implementation of the MNG standard in mozilla.org builds that is enabled by
> default?

Code size. For all the talk about "GIF replacement", most sites will not use MNG
until it's supported out of the box in IE (2 years minimum, if ever). Thus most
users will never see MNG even if we support it fully, so there's some amount of
code that most users will have to download but never use.

Now, we (drivers) are well aware that that alone doesn't settle the argument,
and there are reasons to include MNG (otherwise we wouldn't compromise). But
they have to be balanced against the negative. It's a tough judgement call and I
hope we can all appreciate that reasonable people can make different calls.
Assignee: randeg → jdunn
Status: ASSIGNED → NEW

Comment 238

16 years ago
So essentially you say that the space taken up by MNG-code is more important 
than the space saved by replacing the animated chrome gif with MNG? 
 
Could you please explain how you reach that conclusion, because I sure am not 
able to follow. 
 

Comment 239

16 years ago
Also what about the web developers that want to write server-side scripts to
send MNG if the browser supports it (via the accept header), and GIF if not? It
would be a shame to stop them using a better image format.

Also doesn't KHTML support MNG - possibly another reason why companies like
Apple will choose to embed that rather than Gecko?
Ronald (and others talking about GIF->MNG conversion in the chrome): if I
understand correctly, drivers are concerned with _code_ size.

Chrome images don't contribute to code size, but to the overall package size
instead. They are _data_, not _code_.

Drivers, is that correct?

Comment 241

16 years ago
Rick - KHTML doesn't support MNG.  Konqueror (which is based on KHTML) supports
MNG by virtue of the fact that it's a KDE app, and KDE supports MNG. Safari
doesn't have MNG support.

Apple apparently selected KHTML because the code was smaller and simpler. At the
time they decided, they could have taken Gecko's larger code (which had MNG),
but instead they selected KHTML's smaller code (which didn't).  If getting
people to embed Gecko is a goal, that would be an argument for dropping MNG...

Comment 242

16 years ago
Let's just drop PNG too. I mean who really uses alpha transparency anyway? IE
doesn't support it right, so let's take it out too. Jeez. Why are they adding
all this bloat to Mozilla anyway. I want a tiny little browser that can't view
anything, but the file size will be very small!
Code size?  Isn't that what an ac_add_options --disable-mng is for?  Having
everything optional in Gecko is great design, but it's silly to take it out of
Mozilla for that reason.

IE support?  C'mon, Jerry Baker's right, let's just rip out PNG alpha, MathML,
SVG, etc. to get the code size down.  What's the goal, to make Mozilla a
cross-platform clone of IE?
I read a lot of claims about how converting chrome (the throbber) to MNG saves
more than the library size, but I don't see clear evidence.
http://bugzilla.mozilla.org/show_bug.cgi?id=8415#c85 says we save 40K in
Seamonkey by converting the throbber. The code size for MNG-VLC seems more than
that depending on how it's built (and I don't even know if MNG-VLC is enough to
play the throbber). Download size confuses things because everything's zipped
and the code compresses differently to the images. (Forgive me if I missed a
comment --- there are too many bugs and too many comments.)

Anyway, even if it's true that we can save space overall by MNG'ifying chrome,
that only justifies the minimum MNG configuration required to handle chrome
needs (VLC or LC). I was specifically responding to someone who asked "why not
just include the whole shebang".

Embedding sizes do matter, and that's an issue, but at this point, not as much
as Firebird download size (and Seamonkey to a lesser extent).

[Have the gamma problems that prevented CSS colors from matching MNG/PNG colors
been fixed? I lost track, but it was a stopper for chrome for a while.]

I read a lot of claims about how converting chrome (the throbber) to MNG saves
more than the library size, but I don't see clear evidence.
http://bugzilla.mozilla.org/show_bug.cgi?id=8415#c85 says we save 40K in
Seamonkey by converting the throbber. The code size for MNG-VLC seems more than
that depending on how it's built (and I don't even know if MNG-VLC is enough to
play the throbber). Download size confuses things because everything's zipped
and the code compresses differently to the images. (Forgive me if I missed a
comment --- there are too many bugs and too many comments.)

Anyway, even if it's true that we can save space overall by MNG'ifying chrome,
that only justifies the minimum MNG configuration required to handle chrome
needs (VLC or LC). I was specifically responding to someone who asked "why not
just include the whole shebang".

Embedding sizes do matter, and that's an issue, but at this point, not as much
as Firebird download size (and Seamonkey to a lesser extent).

Although you can turn on and off a whole lot of stuff at build time, we don't
really want people to widely ship builds with different sets of features. If
that happens then "Gecko supports XYZ" becomes meaningless and Web developers
will hate us.

[Have the gamma problems that prevented CSS colors from matching MNG/PNG colors
been fixed? I lost track, but it was a stopper for chrome for a while.]

We obviously do support things that IE doesn't. Like I said, it's a judgement
call, and often a tough one. I'm sorry that you feel that no reasonable person
can disagree with you. Between that, the sarcasm, and the abuse, you shouldn't
be surprised that drivers don't like to talk. And I think I'll shut up now.
To clarify, I completely support reenabling full MNG in Mozilla.

I just wanted to say that I think drivers were misunderstood and converting GIFs
to MNGs in the chrome does not count as justification for big code size of libmng.
> (and I don't even know if MNG-VLC is enough to play the throbber) 
 
no, it isn't. As MNG-VLC can't diwplay _anything_ out there. It's worse than having no MNG, 
because then nobody can say "hey, look how bad MNG is"! 

Comment 247

16 years ago
roc: I haven't converted the animated graphics to MNG myself yet, so I don't
know the actual savings.  However, MNG-VLC is not sufficient to support even the
features that animated GIFs offer.  Without full MNG (or maybe MNG-LC), any
graphics filesize savings would be lost due to missing features like frame
offsets.  I suggest MNG-LC as the baseline install at a minimum, because to the
end user, support for MNG is just bloat without it as MNG-VLC was never meant to
(and can't efficiently) be used for websites.

Comment 248

16 years ago
"if I  
understand correctly, drivers are concerned with _code_ size.  
  
Chrome images don't contribute to code size, but to the overall package size  
instead. They are _data_, not _code_."  
  
Well, that's exactly what I said. Code size is more important than data size  
for some strange reason.  
  
However I don't understand **WHY**.  
 
 

Comment 249

16 years ago
   Excuse me, but isn't putting in support for a subset of MNG that excludes the
majority of existing MNG files rather pointless? If the throbbers people already
made don't even work with MNG-VLC, isn't that an argument for greater MNG
support? Also, I think it is fair to consider the size based on source+chrome.
Even if the source+chrome is bigger for MNG, it's still significant when the
difference for the combined size is 10KB instead of 50KB.

   Also, it's sort of product-centric to consider this solely on the basis of
Mozilla's file size. First, there's the obvious fact that Mozilla supports
multiple themes, which means if you have 10 themes, you're saving 400KB, not
40KB. Also, the smaller file size of MNG files would be of great benefit to
those who want their web pages to download faster. And for embedders, if they're
using a lot of animations, don't those animations take up space?

From olo@altkom.com.pl:
> I just wanted to say that I think drivers were misunderstood and converting
> GIFs to MNGs in the chrome does not count as justification for big code
> size of libmng.

   It doesn't justify neglecting further optimizations of the MNG code in
Mozilla, but it does need to be factored into the equation with regard to
download size.

From roc+moz@cs.cmu.edu:
> Although you can turn on and off a whole lot of stuff at build time,
> we don't really want people to widely ship builds with different sets of
> features. If that happens then "Gecko supports XYZ" becomes meaningless
> and Web developers will hate us.

   This would be an argument for full support of MNG. If you take it out, people
who were using the support provided in previous Mozilla version will hate you.
If you put in a subset of MNG that doesn't support their existing MNG files,
they'll hate you. If the total size of the Mozilla browser is not reduced (not
increased, since it's already in previous versions) by ~50KB, who'd going to
hate you? Name that group that's threatening to drop Mozilla if you don't take
out MNG support. Don't think you're being very realistic on the hatred issue...

   The bottom line is that if MNG support doesn't at the very least support the
most common MNGs in use today, then any change in MNG support in Mozilla will
undermine MNG in general. Removal of full MNG support, while saving an
inconsequential amount of hard drive and memory space, really just amounts to
gambling that MNG will fail as a web file format. If it doesn't, then we will
have slowed the adoption of an important web standard and given Microsoft time
to add support for MNG themselves. If MNG does fail, then Mozilla.org will share
in the responsibility for its failure. You'll forgive me if I don't see the
overall benefit in such a gamble.
mickael: the decision make by Apple to choose Khtml was two years ago, if they
had to choose today, they could make a different choice, unless you consider
that the Gecko code hasn't improved the slightest bit in the last two years and
KHTML is sstill as lightwheighted as it used to be. Furthermore, MS was seeking
browser independance, it was probably not to become dependent on AOL/Netscape
for their new browser. I know of about 15 different browsers embedding Gecko,
apparently MNG support wasn't seen as a problem by other embedders.

I'd rather see the Gecko code improved in areas where it is known to be slow and
bloated than seeing features removed to artificially reduce code size, but
that's just my opinion. As a person with a marketing background, I can see how
this decision is attracting bad press to mozilla well outside the mozilla
community, there are even comments in forums saying that PNG was dropped with
MNG and I don't even talk about how stupid people who were using MNG images to
promote the use of Mozilla and open source feel now, specially in the school
system where computing teachers favorable to open source had banned the use of
animated gif in their classes. BTW, shall we be ridiculous to the point of
opening Tech evangelism bugs for the pages that make use of MNG images and ask
them to replace them with animated GIF images ? ;-)

Comment 251

16 years ago
Mozilla could be the "killer app" that drives the acceptance of MNG as a
graphics format on the internet.  If Mozilla doesn't support MNG images, who will?

I vote for having FULL MNG support - the more things that Mozilla can
interoperate with, the better.

Comment 252

16 years ago
I support FULL MNG.  I work on a source-based linux distribution and perhaps 
that made me realize something: the "embedded" argument is specious and 
ludicrous.  You don't ship a full browser in an embedded environment, you 
manually specifify your own ./configure options and you build it small.  If 
they don't want MNG, embedders that care can easily compile it out since the 
vast majority will be compiling it themselves anyways.  Now, desktop end 
users, on the other hand, are totally different.  They don't compile their 
own, as a universal rule, and thus _need_ to at least have some way to get MNG 
support when Mozilla detects MNGs.  For Source Mage GNU/Linux, we'll most 
likely be packaging MNG enabled by default as a dynamically-linked optional 
dependency of our Mozilla and Firebird spells (to use the system MNG if 
possible), so in the end (for SMGL) it's no big deal what _actually_ happens 
as long as there's a compile option to enable full MNG support, but, 
regardless, even if I can see it, I want as many others to see it.  Why?  In 
my Mozilla evangelism, to graphic artist website developers, I talk about SVG 
and MNG a lot as replacements for things like flash and gif -- well, I found 
out a month or so ago that I couldn't say that Mozilla supported MNG.

Are there any embedded developers interested enough to want Mozilla to be 
small by default without a custom compile against the weight of a few more K 
and the benefit of a complete alternative to animated gif?  Moreover, any 
embedders that won't be compiling their own version?  Morover again, would 
mozilla not make their own binary specifically for the embedded market if 
there was enough pressure?  In sum: the "what about embedded" argument is 
moronic.  Period.

(One part of me doesn't care about animated graphics since I find them 
immensely annoying and disable them wherever I can, but I still support MNG by 
default because it means more website developer flexibility, especially for 
the graphic artists that like alpha transparency and anti-aliasing on 
everything.  I have a hard enough time getting people to switch to Mozilla 
because it doesn't support "exactly" a specific IE CSS extension to scrollbar 
colors that's popular in the graphic artist community.)

Also, the data different than code argument in this example doesn't make sense 
to me, too.  The vast majority of users will probably have a dynamic linking 
system and libmng can be made to not load into memory on boot (if it doesn't 
already do this), but rather, only when it is used.  That makes it the 
same "load" as some chrome images that behave similarly.  Also, for every MNG 
image that people come across that is a MNG instead of a gif (due to the 
browser sending the correct accept header mime type for MNG -- we don't need 
to wait for IE to deploy MNG), you save them that much more bandwidth (why 
limit the benefits to just MNGs shipped with Mozilla?).  "Oh spare them the 
bandwidth" is senseless, and with harddrive space at a dollar per gigabyte, a 
single distracting banner ad on a website will cost more in opportunity cost 
than somebody having a tiny lib that renders full MNG.
guys, MNG won't be a "killer function" for Mozilla, its nice, and it'll probably
be a good thing when it gets supported in wider areas, but given how many people
hate animated images period, how crucial is this really?  I mean, "hey, lets
make better looking animated banner ads, then they wouldn't annoy the crap out
of me!" is not on many people's minds.

Also, libmng isn't installed by default on SuSE 8.2, so I don't think even all
Konqueror installs support MNG either.

As for the "embedded" argument, Firebird and Thunderbird are considered
embeddors in the mozilla.org scheme of things.  Both want the smallest footprint
possible.  Thunderbird disabled MNG before it was removed from the trunk and I
suspect Firebird would have followed suit if not removed from the trunk, given
the footprint savings.  (The removal saved 300k off the firebird .exe,
approximately 4-5% of the total size).

Given the fact that MNG is not a "web standard" per the w3c or used in more than
1% of the rest of the market, dropping this code in the SHORT term loses nothing
substantial to the competition.  Size and performance matter more right now than
support for a little-used standard to users in general, and USERS are the new
focus, and we need to compete based on what it does now, not what it will do in
the future.  Ask that typical user what MNG is, and they won't know, and
probably won't care.  Yes, there's other places that need to be addressed, but
that shouldn't be an excuse for including this.  "There's more bloat elsewhere"
means nothing.  Bloat everywhere is a target, this was just a big and easy size
win, the harder stuff will take longer, but it will happen in time too.
Status: NEW → ASSIGNED

Comment 254

16 years ago
> Given the fact that MNG is not a "web standard" per the w3c or used
> in more than 1% of the rest of the market, dropping this code in the
> SHORT term loses nothing substantial to the competition.

   The only graphics formats that have PNG, JPEG, SVG and WebCGM. MNG and JNG
are based on PNG, so we're really talking about an extension of an existing
recommendation. GIF has a placeholder on their web graphics page (probably for
when the patents run out), but I don't see any kind of W3C recommendation for
it. So when you think about it, MNG is a more legitimate standard that GIF,
since portions of the spec are already approved in the form of the PNG
recommendations.

   As for SHORT TERM loss, MNG stands to loose a lot of legitimacy if a highly
visible application such as Mozilla suddenly drops it after having supported it
for several years. It doesn't benefit us to treat MNG support like some sort of
source code yo-yo that we move in and out of Mozilla at will. It only weakens
MNG as a graphics standard and confuses users and web developers.

> (The removal saved 300k off the firebird .exe, approximately 4-5% of
> the total size).

I'm seeing 240KB on Linux and 170KB on Windows posted previously. Are you
contradicting those numbers?
>> (The removal saved 300k off the firebird .exe, approximately 4-5% of
>> the total size).
>
>I'm seeing 240KB on Linux and 170KB on Windows posted previously. Are you
>contradicting those numbers?

Exact sizes depend on platform.  It was about 300k on Linux prior to any of
my footprint-reduction work.  The 240k was after applying my first patch.

Here are the sizes I'm currently seeing on FreeBSD5.0/gcc-3.2.1, and reported
recently in bug #204520:

                        size libimgmng.so   size -t mozlibmng.a
Original MNG-1.4                288429           182715
MNG_BUILD_FULL_MNG              239922           150008
MNG_BUILD_LC  (includes JNG)    174797            86198
MNG_BUILD_LC (without JNG)      104422            73329
New Default (MNG_BUILD_VLC)      77526            50973
MNG-1.5beta                          0                0

These are of course *uncompressed* sizes.  The effect on download size
is only around 35-40 percent of these numbers.  Note that throbbers,
either in GIF or MNG format, do not compress effectively if at all, so
40K in throbber savings would pretty much offset the size of MNG-LC
without JNG.

Comment 256

16 years ago
From the Webmaster perspective, PNG & MNG are much more useful than GIF.. but..
MNG unfortunately is not yet as widely adopted, and people tend to be a little
slow to see the features, of having such support available.

The only valid point that was made, was that there was not initially a
maintainer for the codebase. Which makes maintaining more difficult..
(particularly when making big changes that could break the non-maintained
code.)... Size was the other valid argument.. but.. it is reasonable that MNG
would be larger. Given it's feature set.

Having some sort of support, even if it isn't close to ideal is better than none
at all. After all, progress is marked by making things better.. Complaints of
missing MNG features will eventually appear. ;-)

I do question why Drivers support MNG-VLC and not MNG-LC (with or without JNG)
based on the recommendations of the PNG-working group.. Far as I know, in
Mozilla's history, following the recommendations of such a library developer has
not been an issue before. 

As far as Firebird is concerned, they were using MNG in the theme that shipped
with it. Until it was removed from the trunk.. So I doubt they were considering
dropping it. They, like the rest of us, probably did wish it was smaller, and
better optimized... though.

As for the maintaining argument, the fact that a serious maintainer was rejected
is a bit puzzling.. Was any reasons given for why Glenn was rejected as a
maintainer? (I'm guessing it's politics.. but..) Do we have another canidate for
a mainainter for MNG? Also, what is the proceedure for becoming said maintainer?
since it hasn't been mentioned here. I'm not sure if I can be of any help, but I
am a supporter of seeing this return, and will help where I can.

As Glenn has proved, there's plenty of room to optimize the different decoders
throughout the imglib module.. which could further improve the performance (and
reduce the footprint). and if optimized along with MNG, it would cover the
existance of the new format. Truth is, new formats are going to come along..
that's a fact that isn't going to go away. Unless you're willing to deprecate
and remove old formats, (which there doesn't seem to be any) to cover for the
new ones.. The codebase size is going to increase, it's just a fact.  The fact
this was branded as "rarely-used" was unfair, as it's new.. and growing (just
not as quickly as some things do).. whereas "rarely-used" when a format is old,
is considered "legacy", and therefore it hangs around, to plague software for
years. I fail to see how if this really is a footprint issue, then all of imglib
isn't being subjected to the fine-tooth comb that MNG was.

This became a hot topic, because of how it happened. There's an injustice in the
way it was removed... Most people respond to situations like this, which is a
good thing. The interest in MNG is good, but the flames really aren't. It's
likely to alienate the supporters of MNG in an enviroment that's already
MNG-unfriendly. Lack of Communication and lack of consideration of others ideas,
played huge roles in the removal of MNG in the first place. Let's prove that we
are more mature than the current owner of libimg. ;-) and work to fix the
problems (both in the code and in the heirarchy), and restore the full-support
of MNG to Mozilla.

-- Wolf

Comment 257

16 years ago
Some comments to address questions brought up in the last couple days:

The reason that drivers went for the VLC profile is that Stuart and I,
not being intimately familiar with the MNG specification, thought that
VLC would at least match GIF's rather modest capabilities.

Glenn was rejected as a maintainer candidate at the beginning because
he had indicated for a long time before that he was opposed to working
in the mozilla codebase.  It's great that Glenn is helping develop
libmng, but the maintainership of that wasn't the problem - Gerard was
already doing a fine job there.  The code we're primarily concerned
about (setting aside size issues) is the glue code that lives in
libpr0n/decoders/mng.

It's great to hear that JNG support weighs in at about 13K, but
unfortunately that comes with the caveat of taking a 102K MNG-LC.
That number is unacceptably high penalty for a file format that is an
extension of one already supported in the mozilla codebase (PNG).

I don't like the argument about saving space with MNG throbbers for a
number of reasons:

  * I believe Glenn was using full profile features when he made those
    throbbers, so those sizes can't be used unless you're talking
    about adding full mng back to mozilla.

  * The GIF versions of the throbbers are not minimal - a little
     experimentation with gifsicle showed they could be smaller.

  * Throbbers using 8-bit alpha will cause mozilla to have a bigger
    footprint and will run slower (significantly so for gtk on a
    remote connection).
>Glenn was rejected as a maintainer candidate at the beginning because
>he had indicated for a long time before that he was opposed to working
>in the mozilla codebase.

"in the libpr0n directory", not "in the mozilla codebase".
See comment #46 and bug #66984.  I withdrew my objection a couple of months
ago when I realized that was a battle of egos and that I might need to work
in that directory anyhow.

Incidentally my ISP is spamkilling any incoming bugzilla messages containing
that directory name, through no action on my part.

> I believe Glenn was using full profile features when he made those
>  throbbers, so those sizes can't be used unless you're talking
>   about adding full mng back to mozilla.

I used full-MNG features, but those features are available in the
MNG_BUILD_LC subset (I explained in bug #204520 that "LC" is a misnomer
because this subset handles MOVE, CLIP, and other things.  It handles the
LOOP chunk as well).

> The GIF versions of the throbbers are not minimal - a little
> experimentation with gifsicle showed they could be smaller.

Download size isn't really all that important, I guess, or someone
would have made them smaller.

> Throbbers using 8-bit alpha will cause mozilla to have a bigger
> footprint

The Firebird throbber that I uploaded had a smaller footprint yet
uses 8-bit alpha to avoid the ugly white haloes that were present in
the GIF.

> and will run slower (significantly so for gtk on a
> remote connection).

Maybe.

Comment 259

16 years ago
  The reason that drivers went for the VLC profile is that Stuart and I,
  not being intimately familiar with the MNG specification, thought that
  VLC would at least match GIF's rather modest capabilities.

Translation, this suggestion was made due to ignorance on your part. Since it
has been clarified that VLC would *NOT* be useful in any way as an alternative
to GIF (and therefore have the opposite effect of what is desired by increasing
the code size without adding any valuable functionality), will you withdraw the
suggestion and change it now to MNG-LC?

  It's great to hear that JNG support weighs in at about 13K, but
  unfortunately that comes with the caveat of taking a 102K MNG-LC.
  That number is unacceptably high penalty for a file format that is an
  extension of one already supported in the mozilla codebase (PNG).

I don't know about you, but I think MNG is worth an extra *20 SECONDS* of
download time on 56K, don't you? (Especially if it is a configurable download.)
Mozilla is already large enough (as would be any full browser package) that it
is practical for a narrow-band user to download it overnight. What difference is
it whether the download finishes at 1:00:00 AM or 1:00:20 AM? I don't find these
size arguments to be significant -- Nobody was interested in the size hits
caused by so many less valuable changes like implementation of MARQUEE, BLINK,
etc. Please, if you can possibly defend your motives... tell us why we should
care about 100KB more than we care about MNG.

  I don't like the argument about saving space with MNG throbbers for a
  number of reasons:

I don't either. So why don't I instead make the argument that if I save 10KB per
MNG image (realistic numbers) it only takes 10 MNG images for the added download
time to pay for itself? I know you won't see any MNG banner ads on Yahoo (Why
would they? All the browsers that support[ed] MNG have some form of
ad-blocking... we're just that good!), but MNG will never become popular if
petty issues like this hinder its progress. And if MNG isn't enabled by default
and built into the binaries for end-user download... nobody will see MNG images
and there's no point to ever having supported MNG in the beginning.

By the way, whoever said we should not implement MNG until MSIE supports it...
thanks for a good laugh. :)

Comment 260

16 years ago
Skewer, I think that you are hurting your own cause (which happens to be mine as
well).  The tone of your last comment was a bit rude and I doubt that it will
help much.  Let's try to leave our egos in the closet and discuss this in a
saner way.

Anyway, it appears that the decision to allow only MNG-VLC in the default build
was based on a misunderstanding of the specs.  I am glad that tor mentioned that
in his comment.  Now I hope that the drivers will change their mind and allow
MNG-LC in the default build, so that animated GIFs can be replaced easily.

It would be nice to include JNG as well, but I could live without it for the
next release (as long as it can be enabled in non-default builds).  But I hope
that we will at least get MNG-LC.

Comment 261

16 years ago
   Perhaps this would be a good time to figure out what the majority of us would
agree on. The following seems to be the general consensus:

1) MNG-VLC is unacceptable because its feature set isn't sufficient to make it a
replacement for Animated GIFs, thus making the format unattractive for web
developers. Including MNG-VLC would provide benefit neither to Mozilla nor the
MNG format. It was probably never the intent of the Drivers to select such a
subset. I believe they were simply misinformed.

2) MNG-LC is an acceptable for replacement Animated GIFs and should be part of
whatever level of MNG support is restored to the Mozilla trunk.

3) The MNG_BUILD_LC configuration is an acceptable compromise for the majority
of MNG supporters who use Mozilla because it supports a mild superset of MNG-LC
that allows Mozilla to display the majority of MNG files currently in use. (Let
me know if this is not the case.)

4) JNG support is highly desired, but there are many who feel restoration of JNG
support can be eliminated in the short term if it allows MNG restoration to go
forward.

   That last part is a bit ironic from a W3C point of view. It's my
understanding that JNG is simply a variation of PNG that supports JPEG
compression. Since both PNG and JPEG are W3C recommendations, and the lack of
sufficient compression in PNG for true color images is one of the major
arguments against using it in web graphics, one would think JNG would not only
be an obvious format to add to a browser, but would also be fairly easy to get a
W3C recommendation for. I suppose the real argument here is whether alpha
channels are more valuable than patent-free animation. Personally, I'd rather
see JNG included, but I'm not sure I'd push the JNG issue at the expense of MNG.
Then again, much of the savings in MNG data size comes from the use of JNG, so
removing it may not work in our favor.

There are still some questions to be answered, though, before we can make
headway in discussing MNG support:

Q1) Do the Drivers(TM) actually have a maximum size in mind for MNG code? (If
creative optimization could bring full MNG support below a code size target
predetermined by the Drivers, then we're wasting our time even talking about
levels of MNG support.)


Q2) Is JNG a critical feature? Is JNG, on its own, worth supporting in Mozilla?

   Input from the Drivers is important here. The Drivers need to be more clear
about exactly what they want and are willing to live with, while we need to cut
them some slack and realize that they're not evil Hellhounds come to devour the
soul of our precious baby MNG.
>There are still some questions to be answered, though, before we can make
>headway in discussing MNG support:
>
>Q1) Do the Drivers(TM) actually have a maximum size in mind for MNG code?

Greg wrote drivers on behalf of himself, Gerard, and me a while back asking
them to clarify that specific question.  The answer (comment #200) did not
impose any particular limit.  I interpreted that to mean whatever we can
achieve at the moment, with a committment to continue reducing the footprint
as much as possible.

> Q2) Is JNG a critical feature? Is JNG, on its own, worth supporting in 
> Mozilla?

I would say no, and yes.  To see what JNG can do, look at http://pmt.sf.net/opossum
using a JNG-capable viewer (doesn't work with Firebird + MNG XPI because SF
sends the wrong MIME type, so you may need to download the page and images and
view it locally.  Doesn't work with Moz-1.4 on Windows2k and later because of a
Microsoft compiler bug for which I provided a patch that is awaiting r/sr).  It
is JPEG combined with PNG-style alpha-transparency, which allows you to get nice
antialiased edges and translucent drop shadows.
More official response in a private message to me, Greg, and Gerard:

Since it was brought to our attention that MNG-VLC is not appropriate 
for replacing animated GIFs, it's clear that asking for MNG-VLC was a 
mistake. We'd like to have MNG-LC enabled instead. We'll strongly 
consider enabling support for JNG-chunks, too, once we've seen the final 
footprint numbers.

There is one other thing we'd like to clarify. The above is contingent 
on figuring out a way to have MNG and PNG share the PNG code, preferably 
by having the MNG support use libpng. I realize this might be hard work 
but there is no way to justify shipping two PNG implementations.

Thanks for all your work. We really appreciate it, although I know that 
sometimes it may not look that way.

Comment 264

16 years ago
Reading through the MNG specification, it's looking as though MNG-LC can't
perform the GIF restore-to-previous discard method.  Is that the correct
interpretation?
that is correct, MNG-LC cannot do GIF restore-to-previous disposal method.  The
code built by libmng with the MNG_BUILD_LC macro can, however.  I am going to
rename MNG_BUILD_LC to MNG_BUILD_WEB_MNG and reduce the code produced by
MNG_BUILD_LC to approximately what's required by the actual MNG-LC specification.
Here is an update of my results, requested off list by a Driver.

The MNG_BUILD_LC/LC_JNG are renamed MNG_BUILD_WEB_MNG/JNG and
new MNG_BUILD_LC/LC_JNG represent code that implements approximately
the MNG-LC specification.  Note that "web" is about 10k larger,
uncompressed, than "lc".  "web" in my opinion is the minimally
useful configuration for a browser.

                        size libimgmng.so   size -t mozlibmng.a
Original MNG-1.4                     288429           182715
MNG_BUILD_FULL_MNG                   239922           150008
MNG_BUILD_WEB_JNG (includes JNG)     174797            86198
MNG_BUILD_WEB_MNG (without JNG)      104422            73329
MNG_BUILD_LC_JNG  (with JNG)         164659            77978
MNG_BUILD_LC      (without JNG)       94300            65129
New Default (MNG_BUILD_VLC)           77526            50973
MNG-1.5beta                               0                0
Argh. So MNG-LC, previously advocated as the "animated GIF replacement" subset
of MNG, isn't. So in fact there is no "standard" subset of MNG, short of full
MNG, that serves as an "animated GIF replacement"? That's a bummer.
BTW, who has volunteered to maintain the libpr0n MNG code (i.e.,
mozilla/modules/libpr0n/decoders/mng)? Are you all expecting Pavlov to do that?
<i>The above is contingent on figuring out a way to have MNG and PNG share the
PNG code, preferably by having the MNG support use libpng</i>

Finally we know the main (valid) reason for the original removing of mng!!

Thank you, now we understand a lot more what is wanted.
> Argh. So MNG-LC, previously advocated as the "animated GIF replacement" subset
> of MNG, isn't. So in fact there is no "standard" subset of MNG, short of full
> MNG, that serves as an "animated GIF replacement"? That's a bummer.

The MNG spec has always mentioned that MNG-LC cannot do restore-to-previous.
Arghh indeed.

> BTW, who has volunteered to maintain the libpr0n MNG code (i.e.,
> mozilla/modules/libpr0n/decoders/mng)?

I did but was found unacceptable.  I'm no longer seeking that job and won't
accept it if offered.

>Are you all expecting Pavlov to do that?

That would be nice.  See bug #204520, comment #65, near the bottom: "I am
willing to help."

The libpr0n part of MNG support is only a few hundred lines, most of
which are very similar to the relevant code for supporting other formats.
And Pav wrote it so doubtless understands how it is supposed to work.

>>The above is contingent on figuring out a way to have MNG and PNG share the
>>PNG code, preferably by having the MNG support use libpng</i>
>
>Finally we know the main (valid) reason for the original removing of mng!!

Why is it a valid reason, to throw out the existing libpng and libmng, both of
which work, and write a new extended libpng that supports both?  The most that
could be saved by the (substantial) effort would be 30k, which is the size of
libpng with all of my footprint-reduction work checked in, plus perhaps a few k
in libpr0n.  It is claimed that the single library would require less
maintenance, but that maintenance would fall upon mozilla maintainers, not the
current 3rd-party libpng and libmng maintainers.
OK, so here's my understanding of where we're at.

The duplication of PNG code in MNG can't be easily removed. Glenn says maybe in
a year. This is a design flaw and a problem for codesize, maintainability (fixes
may need to be applied in two places), and consistency (different PNG bugs
depending on how you package your PNG).

Pavlov doesn't want to maintain the libpr0n/MNG glue code. So there's no
maintainer for that.

There is no standard subset of MNG that fully replaces animated GIFs. So we're
stuck with either the full library or a subset that Glenn cooked up, which we're
not sure anyone else will actually use.

These problems will all need to be addressed before we can resolve this bug.

Comment 273

16 years ago
Almost certainly any patches would be made directly against libpng.  These MNG
"mozilla maintainers" that you speak of.  Who are they?  I think you missed one
of the original reason that MNG was removed.  There is no Mozilla MNG
maintainer.  The responsibility for writing this code is left in the hands of
those who want the feature in the tree.  It is up to you, Glenn, to come up with
a way to solve the issues at hand.  Hopefully Greg and Gerard can help you out.

It seems pretty clear that what drivers and myself are interested in is a PNG
based animation format that can replace GIFs and thats it.  A subset of MNG
various MNG parts would certainly be ideal.  Perhaps a new MNG-GIF or whatever
"profile" should be put together that only contains those things needed to
replace GIF since it sounds like both MNG-VLC and MNG-LC are both inadiquate.  

I'm still baffled by how the MNG creators were able to make "small" profiles
that can't replace GIF.  What were they thinking?  Also, why was a seperate
library made instead of adding the MNG featureset on top of libpng?

Comment 274

16 years ago
From roc+moz@cs.cmu.edu:
> There is no standard subset of MNG that fully replaces animated GIFs. So we're
> stuck with either the full library or a subset that Glenn cooked up, which
> we're not sure anyone else will actually use.

   As opposed to MNG-VLC, which we KNOW nobody will use. ;)

From Stuart Parmenter:
> I'm still baffled by how the MNG creators were able to make "small" profiles
> that can't replace GIF.  What were they thinking?

   Actually, I was just thinking that we should create a specification for the
subset of MNG that Mozilla eventually ends up using. Perhaps "MNG-WEB" or
"WebMNG"? This would let developers of graphics tool know which portions are or
are not supported in Mozilla.

> Also, why was a seperate library made instead of adding the MNG featureset
> on top of libpng?

   I was under the impression that libMNG supported PNG files. Why can't the PNG
support simply be rewritten to us libMNG? Wasn't that the whole point behind Bug
48893? I think the problem here is that libMNG is newer, and therefore
considered less stable than libPNG. There's also been some suggestion that
libMNG will eventually utilize libPNG directly to avoid code duplication. Is
this correct?
>There's also been some suggestion that
>libMNG will eventually utilize libPNG directly to avoid code duplication. Is
>this correct?

No, the idea was that when libmng reaches the maturity level of libpng we will
drop libpng and use libmng to handle standalone PNGs.

That doesn't square with recent comments though.  We seem to have a brand-new
requirement that we use a single library to handle standalone PNGs and
MNG-embedded PNGs immediately.

Comment 276

16 years ago
Robert : There is no standard subset of MNG that fully replaces animated GIFs. 
         So we're stuck with either the full library or a subset that Glenn cooked 
         up, which we're not sure anyone else will actually use.

Considering the fact that this bug currently has 559 votes, I think it is reasonable to assume that 
there are some people who would use the MNG support if it were implemented.  Also I can assure 
you that I personally know of at least 67 people who would use it (right now they are all using  
builds of Mozilla that have MNG support).  If you are worried about people hating you then be glad 
that I have not told everyone about the decision to drop MNG support.

It is unclear to me why you have a problem with whether or not Glenn's MNG_BUILD_WEB_MNG and 
MNG_BUILD_WEB_JNG subsets are "standard" or not.  They are simply MNG_LC with a few extra 
features so that it can effectively replace all animated GIFs.  What difference does it make if it is a 
"standard" subset?

Pavlov : It seems pretty clear that what drivers and myself are interested in 
         is a PNG based animation format that can replace GIFs and thats it.  A 
         subset of MNG various MNG parts would certainly be ideal.  

It sounds like you are describing Glenn's MNG_BUILD_WEB_MNG which was introduced several 
comments ago.  

Pavlov : I'm still baffled by how the MNG creators were able to make 
         "small" profiles that can't replace GIF.  What were they thinking?

I am not sure what you are asking, but I will try to answer.

If you are talking about the actual creators of the MNG format then the answer is that they were 
not so narrow minded as to think that replacing GIFs was the only purpose for the MNG format.  

If you are talking about MNG_BUILD_VLC then the answer as to why they did it is quite simple.  
Drivers asked them to do it.

If you are talking about MNG_BUILD_LC then the answer is that the original MNG_BUILD_LC actually 
WAS able to replace GIFs.  The new MNG_BUILD_LC was created for sake of accuracy when the old 
one was renamed MNG_BUILD_WEB.

If you are talking about something else then you will have to explain the question further.

Comment 277

16 years ago
Mark: I wasn't refering to anything you just replied about.  Next time you reply
to someone, maybe try and see if they were actually talking to you or not.

Comment 278

16 years ago
As long as Glenn's "WEB_MNG" configuration can *gracefully* work with any fully
standardized image that's the idea...

Glenn, will we lose any of the following in that "WEB_MNG" configuration?

True color / Alpha transparency / Gamma correction

All are features that are very important, but are not supported by animated GIF.
I wouldn't be willing to sacrifice any of them for just a quick alternative to
GIF. Actually, speaking as a web developers, if I could have a format which has
those features and otherwise does anything GIF does, that's already adequate for
any realistic application. There are countless special features to MNG that
don't really have any usefulness at all, I realize from looking at the test
images in MNGsuite. Just like there are JavaScript functions that are virtually
useless that only work in certain browsers, those goofy MNG functions have no
place in Mozilla unless we want to pop up on a DynamicDrive.com type of site.
These kind of features might even be present in MNG_LC but not necessarily
valuable to web developers. If we can be ruthless with this (sure, someone might
find scrolling text MNG images cool, but is it worth having?) we can probably
get a good reduction without the need to squeeze libmng and libpng together
(which for the record, I oppose).

Comment 279

16 years ago
skewer: no one is wanting to remove any core PNG functionality.  It is the MNG
featureset that is in question.

If you don't have something useful to add to this bug, please don't post it in
here.  This bug is already more than useless.  Pretty much unless you are
directly involved with resolving this bug, there is no reason for you to post
anything in here anymore.  Please go find some other bug to troll in.

Comment 280

16 years ago
Pavlov: Your attitude towards people in general is not quite justified.  No
matter that this is or isn't a /forum/, both here and in 204520 you yourself
either belittled others, or acted selfish and quick-on-the-gun, or came up with
out of the scene ideas (ideas about libmng sizes in 204520 for example).
I mean, right, I do not know you, you are most surely a better programmer than
myself, but I'm very sure that you aren't building a nice picture about yourself
in your public posts.  As for what you do in private messages to Glenn or anyone
else -- well, we don't know about that, but your public behaviour is starting to
become ridiculous.

Someone suggested that we all leave our egos behind and try to communicate in an
intelligent manner.  That means you too, so please.

You are right about that Skewer didn't read the things well enough (or at least,
I agree on that with you).  In this Mark issue I too thought you were talking
about MNG's creators making up stupid subsets -- so I now come to the conclusion
that we don't have telepathic powers, and as such I'd like to ask for some form
of written communication that tries to fit these criteria.

--
R, not enjoying to be off topic.

Comment 281

16 years ago
Henrik, I've posted all of 1 time in this bug prior to today and I've posted
exactly 1 time in the other bug, and that was only quoting an email that I had
sent.  My comments towards Mark were uncalled for, but people have to realize
that this bug has gone out of control.  The extra comments in here have got to
stop as they are just wasting my time and the other people trying to resolve
this bug's time.  I did not come up with the library size numbers in my email on
my own and most developers I have spoken with believe they are quite reasonable.
 Almost all of my discussions relating to this issue occur through email as
bugzilla isn't a discussion forum.

Comment 282

16 years ago
Breaking standards is evil.

At least that is what everybody says if Microsoft does it. Standards exist for a
reason. It brings compatibility between applications. Any image editor/viewer
supporting MNG would follow the standard. If Mozilla chooses to implement a
non-standard MNG subset, there will be a lot of "MNG image does not work" bug
reports. Could you imagine if there were JPEGs and Mozilla JPEGs. PNGs and
Mozilla PNGs, XML and Mozilla XML, HTML and Mozilla HTML?

We constantly bash Microsoft for breaking standards and here we are with Mozilla
doing exactly the same thing. If Mozilla breaks the MNG standard, then we should
all shut up about Microsoft Internet Explorer having broken PNG support. After
all, all Microsoft did is implement a PNG subset, supporting GIF features.

Mozilla has a virtual monopoly for viewing MNG images, but does that mean is
should abuse that monopoly? If something is wrong with a standard, then the
standard should be changed not broken.

There are more reasons to support the full standard. If PNG is just a GIF
replacement, why not limit Mozilla PNG support to 256 colors and remove its
alpha channel support? My guess is that the world would be too small. Both PNG
and MNG/JNG are attractive, because of their expanded feature sets.

The argument of PNG/MNG being a GIF replacement is also faulted. GIF patent
issues are already over in the USA and starting June 2004 will be over anywhere
else. Do we drop PNG and MNG support on that date?

A MNG subset is not MNG and if MNG/JNG is seen as a valuable addition (and I too
think it is) then it should be implemented fully according to the standard.
Breaking standards (ie implementing a subset) brings us in Microsoft territory.
> Glenn, will we lose any of the following in that "WEB_MNG" configuration?
> True color / Alpha transparency / Gamma correction

No.  We lose deltaPNG and 16-bit support (16-bit images are downgraded to
8-bit during decoding so you won't see much difference on your screen).

I mistakenly removed PAST chunk support yesterday from WEB_MNG and will restore
it shortly, at a cost of around 5kbytes.

The rest of the features that are removed are ones that Mozilla doesn't use
anyway.

If you try to read a MNG file that uses DeltaPNG, you will get the "image cannot
be displayed because it contains errors" message.  Any other files should be
shown OK (with possible degradation due to 16-bit to 8-bit downgrading).

If you configure --with-system-mng or if you use the MNG XPI then DeltaPNGs
will be OK and there won't be any 16-bit to 8-bit degradation.

Comment 284

16 years ago
   Jan Derk, it is quite common for programs to support SUBSETS of file formats
like MNG. This is not breaking a standard, and forcing everyone to support every
last feature in a spec like MNG's is not always reasonable.

   What Microsoft has frequently done, however, is to make ADDITIONS to a
standard that weren't part of the standard to begin with and break the
extenstion model set up for that standard. Their Java (later known as the
Microsoft VM) is an excellent example of this.

   What "MNG-WEB" tries to do is implement a subset of full MNG format that will
still work if rendered by a full MNG implementation. (I'm hoping it also
supports Dynamic MNGs. I'm looking forward to creating web pages with Dynamic
MNG.) This can be good or bad depending on the following:

1) Are the features supported by MNG-WEB going to be documented so that people
can create efficient MNG files that work with Mozilla?

2) Will MNG-WEB lack features needed by some web developers?

3) Is MNG-WEB a true stepping stone to the eventual reintroduction of full MNG
support, or just a way of quieting down the MNG community while shaving some
code size from Mozilla?

   On a side note, I do think that the situation for this bug has gotton out of
hand. While I dispute the idea that this is not the place for a discussion on
the bug to take place, I do feel that there has been a lot of nonproductive
conversation, and that at this point Bug 18574 is too broad, considering all the
issues involved in MNG support. Perhaps the best solution is to break this bug
apart into separate bugs that cover the following:

- Restoring JNG support.
- Restoring MNG-LC/MNG-VLC support.
- Restoring "MNG-WEB" support.
- Restoring full MNG support.

   In this way, I believe we can get better feedback from the Drivers, more
focused discussions, and the votes for each bug can be used to gage the
importance of each of these to the community at large.

   Just read Glenn's message. Glenn, are you saying that MNG-WEB for the most
part only exclude features Mozilla couldn't use anyway?
1) Are the features supported by MNG-WEB going to be documented so that people
can create efficient MNG files that work with Mozilla?

   It's just a snappier name for profile 975 found in the MNG spec.  And
   MNG_BUILD_WEB_JNG equates to profile 991.

2) Will MNG-WEB lack features needed by some web developers?

   Yes, it lacks DeltaPNG which includes some goofy things like palette
   animation.

3) Is MNG-WEB a true stepping stone to the eventual reintroduction of full MNG
support, or just a way of quieting down the MNG community while shaving some
code size from Mozilla?

   It doesn't seem to be either at this point.  It is merely a huge waste of
   my time.  "Shaving" some code size?  It's been cut about 60 percent.  That
   more like major surgery.
Status: ASSIGNED → NEW
Jan Derk's comment is quite correct, and explains exactly why we can't just ship
some random subset of MNG such as Glenn's WEB_MNG, which would essentially be
Mozilla-MNG.

Saying it's "profile 975" isn't a good answer. "975" is just the setting of 9
feature bits. It isn't given a proper name anywhere in the spec or listed as a
reasonable development target.
> Jan Derk's comment is quite correct, and explains exactly why we can't just 
> ship some random subset of MNG such as Glenn's WEB_MNG, which would essentially 
> be Mozilla-MNG.

OK, I added one more configuration for testing purposes.  The macro is
MNG_BUILD_MOZ_MNG and the result is a full MNG implementation with various
footprint reductions that don't reduce the feature set other than removing
features that Mozilla wasn't using.  It handles 16-bit samples by demoting
them to 8-bit while reading.  It does handle DeltaPNG and JNG.
See bug #204520.

Size on my FreeBSD5.0/gcc3.2.1 platform are
mozlibmng.a 107877 and libimgmng.so 200835.

>Saying it's "profile 975" isn't a good answer. "975" is just the setting of 9
>feature bits. It isn't given a proper name anywhere in the spec or listed as a
>reasonable development target.

It was an answer to the statement that MNG-WEB should be documented.  "975"
is listed in the spec as "MNG without DeltaPNG or JNG".

MOZ-MNG would be profile 1023 which means complete MNG support.

There have been some comments that DeltaPNG is about 'goofy' stuff like pallette
shifting.  Actually, it's about image-compression:

"Several movies of finite-element calculational results by the U. S. Army
Research Laboratory required only about a quarter of the file space when
converted from a simple series of PNGs to delta-encoded PNGs."

Previous comments indicate the size of the DeltaPNG code is about 7k.  Surely if
anyone ever hits a delta-png, just once, the download size will have been made
up for.  I'm fairly interested since I'm among the 60% of users who can't/won't
get broadband.

This isn't new territory in motion image compression - all the MPEG specs are
based on delta images.

I see a parallel with the gzip content-compression code.  A tiny code fragment
greatly improves the low-bandwidth experience.

Comment 289

16 years ago
Here's the numbers again. Hope I didn't mess anything up...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                             size libimgmng.so   size -t mozlibmng.a

File Sizes:

Original MNG-1.4                     288429           182715
MNG_BUILD_FULL_MNG                   239922           150008
MNG_BUILD_MOZ_MNG                    200835           107877
MNG_BUILD_WEB_JNG (includes JNG)     174797            86198
MNG_BUILD_WEB_MNG (without JNG)      104422            73329
MNG_BUILD_LC_JNG  (with JNG)         164659            77978
MNG_BUILD_LC      (without JNG)       94300            65129
New Default (MNG_BUILD_VLC)           77526            50973
MNG-1.5beta                               0                0

Savings over Mozilla 1.4:

MNG_BUILD_FULL_MNG                    48507            32707
MNG_BUILD_MOZ_MNG                     87594            74838
MNG_BUILD_WEB_JNG (includes JNG)     113632            96517
MNG_BUILD_WEB_MNG (without JNG)      184007           109386
MNG_BUILD_LC_JNG  (with JNG)         123770           104737
MNG_BUILD_LC      (without JNG)      194129           117586
MNG_BUILD_VLC                        210903           131742

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   That's a log of options, and all of them save considerable space over Mozilla
1.4. MNG-VLC and MNG-LC are non-starters due to the fact they can't
realistically compete with GIF, so we can throw them out. MNG_BUILD_FULL_MNG
doesn't really offer anything significant over MNG_BUILD_MOZ_MNG, so let's toss
it out too. That that just leaves us with this:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                             size libimgmng.so   size -t mozlibmng.a

File Sizes:

MNG_BUILD_MOZ_MNG                    200835           107877
MNG_BUILD_WEB_JNG (includes JNG)     174797            86198
MNG_BUILD_WEB_MNG (without JNG)      104422            73329
MNG-1.5beta                               0                0

Savings over Mozilla 1.4:

MNG_BUILD_MOZ_MNG                     87594            74838
MNG_BUILD_WEB_JNG (includes JNG)     113632            96517
MNG_BUILD_WEB_MNG (without JNG)      184007           109386
MNG-1.5beta                          288429           182715

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   Now if we had a size target, like I'd suggested, the debate would be over.
Simple math. If the target was ~180KB, we'd go with MNG_BUILD_WEB_JNG and focus
on reducing the size of MNG_BUILD_MOZ_MNG so we could use that later. If they
want ~50KB, we continue to try and convince them otherwise while working on the
plug-in. One could argue that MNG-WEB isn't sufficient, but it's a heck of a lot
better than nothing, and I think most of us would take it if we had no other
choice. There doesn't seem to be a whole lot to debate here.

   Unfortunately, we have no hard targets to hit, so we end up in a massive MNG
civil war about who's feature to kill. The Drivers need to step in and give us
an idea of what they think is reasonable with regard to size and features so
that this discussion doesn't wander into the impractical and the purely theoretical.
One of you wrote me privately asking for one set of numbers (I did not
upload a patch to actually install this macro):

MNG_BUILD_MOZ_MNG_NO_JNG    130329           93980

libimgmng.so.gz is 52k which would be about the effect on download size.

However, the important number is still
MNG_MOZ_ACCEPTABLE_VOLUNTEERS   0

Comment 291

16 years ago
  Jan Derk's comment is quite correct, and explains exactly why we can't just
  ship some random subset of MNG such as Glenn's WEB_MNG, which would 
  essentially be Mozilla-MNG.

  Saying it's "profile 975" isn't a good answer. "975" is just the setting of
  9 feature bits. It isn't given a proper name anywhere in the spec or listed
  as a reasonable development target.

Glenn: Just so I'm not misunderstanding... These subsets of MNG you've been
putting together will load virtually any MNG image that doesn't use those
intentionally excluded features, right? As long as anyone could use one of the
MNG-supporting graphics apps to create MNG images and they would work fine in
Mozilla, that's what matters. It's not fair to developers to have to do anything
special to their images to have them work in Mozilla. If I'm correct then I see
no reason to build MNG a certain way to make it match a standard, as long as it
still works right for displaying MNG images.

Comment 292

16 years ago
I really can't understand the point of removing a working feature based on a  
working-draft of a web standard for the sake of 300k. 
  
Three Hundred Kilobytes.  
  
That is one five-hundred-thousandth of my hard disk space.   
  
"lets see what we can do now.. i know, lets remove support for jpeg, that ought  
to make the footprint smaller"   
  
What next, remove support for HTML?  
 
The sheer number of votes and comments for this bug shows how stupid an idea it 
is to remove MNG support. 
> Three Hunded Kilobytes

It Two Hundred Kilobytes now: MNG_BUILD_MOZ_MNG  200835
This build provides FULL MNG SUPPORT.  No features are excluded.

> Glenn: Just so I'm not misunderstanding... These subsets of MNG you've been
> putting together will load virtually any MNG image that doesn't use those
> intentionally excluded features, right?

Right.

Comment 294

16 years ago
I think this is an important distinction to make.

Based on the comments, people seem to fear MNG being built "A certain way"
because of the perception that this build will require "special effort" on the
part of MNG creators to be conformant to spec 975.

My understanding is that this is not the case, that MNG's *will* work "out of
the box" when created as animated GIF replacements, with no special tweaking.
This is an important point - if content *creators* need to do nothing different
to support MNG_BUILD_WEB_MNG, then we are *not* being incompatible, and we are
*not* creating a situation where People will start considering this MNG
implementation as MOZ-MNG, IMHO.

Comment 295

16 years ago
Ken: That only assumes that developers are _only_ looking for an animated GIF
replacement and will not use other features.  The comparison brought up before
was the IE PNG implementation: IE doesn't support the alpha channel, but
supports enough of the standard to be a strict GIF replacement.  The same
problems will eventually occur when MNG becomes more widespread.

Comment 296

16 years ago
Re: comment #290
This one strikes home since I've been meaning to fix a bug I ran into with MNG
and still haven't found the time.
However, I would not have run into the bug if I hadn't stayed at 1.4 (MNG is the
reason I stopped using nightlies).
Eliminating MNG is a good way to guarantee that number will never rise above 0.

Comment 297

16 years ago
  Ken: That only assumes that developers are _only_ looking for an animated GIF
  replacement and will not use other features.  The comparison brought up before
  was the IE PNG implementation: IE doesn't support the alpha channel, but
  supports enough of the standard to be a strict GIF replacement.  The same
  problems will eventually occur when MNG becomes more widespread.

We need to use judgment on what most web developers won't use... Some features
might be powerful but fairly unlikely to appear in, say, an ad banner or intro
page just because of the effort involved in putting together a MNG image that's
capable of doing that. Priority 1 is just supporting images that have been put
together by an Animation Shop-type program. The best part is if some feature
someday becomes important we can add it back in later!

Comment 298

16 years ago
Exactly - The focus here should really be on adding just those features needed
to provide MNG support for the majority of MNG's on the web /today/. We can RFE
in the additional features as popularity grows.

Also, remember that the *full* MNG spec is not even used entirely by Mozilla
anyway, so we were implementing a "subset" of MNG even in 1.4. :)
1.4 implemented FULL MNG.  Not a subset.  It worked fine until it was
sabotaged on June 3.  Some ancillary chunks weren't used (iCCP, cHRM, etc)
but files containing them were processed correctly.

Comment 300

16 years ago
   "We can RFE in the additional features as popularity grows."

Ya. Considering the dismal rate at which RFE bugs are addressed in Mozilla (1965
fixed out of 6500+), that seems about equivalent to saying never implement the
additional features.

Comment 301

16 years ago
Supporting a Subset of the MNG specification is a balancing act. It makes some
logical sense when looked at like this...

Because it's a relatively new format, and not *yet* widely used... It makes it
difficult to be able to continue to justify having the entire thing included..
(although it *was* there.. go figure..) Although, I don't think it's an
unreasonable assumption to make, that when the format is more widely used,
increasing the features Mozilla supports will not run into as many problems as
we currently face. 

So, the idea has evolved to supporting what's needed to make it useable support.
Being careful not to make mistakes that may come back to haunt us.. (Similar to
Microsoft's decision to leave out Alpha support for PNG with IE on Windows).. 

So, we leave out what isn't *needed*... and try to make the most complete (while
still remaining useable)... Creating a strict GIF-Replacement, doesn't do the
format justice.. because of the enhancements it has over GIF. But, at the same
time, providing the features to convert from GIF to MNG easily is probably a
decent idea.. (since migration away from GIF is kinda expected by this format).

As long as the subset Mozilla implements is completely based on the standard
(I.E. not adding anything special... or not supporting something seriously
required)... then I believe that there isn't a big problem there.. (Feel free to
correct me if I'm wrong though).

From my understanding.. libmng was designed to be a eventual replacement for
libpng, supporting PNG as well as MNG/JNG images.. (correct?) but what's being
proposed now, is extending the current version of libpng Mozilla uses, to
include the same support.. Why? I realize libpng has the benefit of being more
tested than MNG.. but other than that, what prevents the use of libmng to handle
the current functions of libpng as it appears to have been designed? (and still
remove the duplicated code in the process) But.. neither of these are good as a
short-term goal.. (Showing my software development inexperience here) Is it
possible to build an experimental version of Mozilla where libmng handles PNG?
(assuming both libpng and libmng were back avaiable).

Excluding that particular debate.. which has been going on awhile.. (Bug #48893
has been around since 2000-08-14 (or 3 years. after all)). That leaves us with 2
other specific issues..

(1) Select a subset of MNG functionality that will work for our needs..

(Numbers previously posted):
                        size libimgmng.so   size -t mozlibmng.a
MNG_BUILD_MOZ_MNG                 200835    107877 (All but Moz Unused Features)
MNG_BUILD_WEB_JNG (includes JNG)  174797     86198 (Former Build LC_JNG)
MNG_BUILD_MOZ_MNG_NO_JNG          130329     93980 (Moz Unsed excluding JNG?)
MNG_BUILD_WEB_MNG (without JNG)   104422     73329 (Former Build LC)

Savings over Mozilla 1.4:
MNG_BUILD_MOZ_MNG                  87594     74838
MNG_BUILD_WEB_JNG (includes JNG)  113632     96517
MNG_BUILD_MOZ_MNG_NO_JNG          158100     88735
MNG_BUILD_WEB_MNG (without JNG)   184007    109386

In an ideal world, we'd pick MNG_BUILD_MOZ_MNG (the whole thing minus what Moz
doesn't need)... but I have a feeling that 200835 is still too large at the
current time to be justifyable.. Leaving out JNG support and dropping to it's
smaller brother, MOZ_MNG_NO_JNG would bring it down to 130329, which to me, is
an acceptable increase.. Now based on the summary of this bug, that
configuration would not RESOLVE this bug, but, it's a start.

The other 2 configs.. WEB_JNG and WEB_MNG which are around 25k smaller.. leave
off parts of the MNG specification that may actually be used.. (DeltaPNG was
mentioned specifically). According to posts here, Delta-PNG allows files to be
much smaller, resulting in faster browsing. So, assuming somebody hits a file
and this part of the code is used, the size is made up for.. (also, if it
becomes a widely used part of MNG in practice, and it's not supported in Moz..
then the implementation is useless. No matter how much space it saves.) I assume
Delta-PNG is supported for PNG under libpng?

Based on what has been said, the WEB_MNG config is the minimal that we could
use.. (Based on Drivers request for a GIF replacement.. (restore-to-previous was
specifically mentioned in the discussion as being missing under LC but in WEB).
So, under my understanding the differences between the WEB vs. Moz is Delta-PNG
(only thing that's been mentioned by name).. and obviously, between each of
those and their smaller half-brothers would be whether or not JNG is included)..

So, the questions are, how important to us is Delta-PNG and JNG support? if we
need to pick one? which? and is it practical to pick either? The current numbers
speak for themselves... 

(2) On to the second problem, that needs resolving...
For any of the above to matter, MNG needs a maintainer for libpr0n/MNG code.. (I
think that's all that's missing a maintainer.. as long as we're still using the
extenal library) Anybody willing to help out here? I would volunteer as I have
the time.. but my programming skills are beyond insufficent for such a task. heh..

Hope that discussion helps..
-- Wolf
>increasing the features Mozilla supports will not run into as many problems as
>we currently face. 

It would be a simple matter of turning off the macro(s) that disable(s) the
feature(s) being added.  Technically no problem but will require a lot
of squabbling in bugzilla about file size versus feature set.

>From my understanding.. libmng was designed to be a eventual replacement for
>libpng, supporting PNG as well as MNG/JNG images.. (correct?) but what's being
>proposed now, is extending the current version of libpng Mozilla uses, to
>include the same support..

That is pav's proposal but I don't think anyone else endorsed it.  It means
throwing away two working third-party libraries, libmng and libpng, and writing
a new one specifically for mozilla.

>Is it
>possible to build an experimental version of Mozilla where libmng handles PNG?
>(assuming both libpng and libmng were back avaiable).

As I've said before, just have libmng handle PNG files that have the .mng
suffix.

>In an ideal world, we'd pick MNG_BUILD_MOZ_MNG (the whole thing minus what Moz
>doesn't need)... but I have a feeling that 200835 is still too large at the
>current time to be justifyable..

This is easily reduced about 60k by removing the extra copy of libjpeg.

> I assume
> Delta-PNG is supported for PNG under libpng?

It is not, and that is the major reason libmng's support for standalone PNG
files requires more code, memory, and time that libpng does.  At the time a
PNG file is being read, libmng does not know whether it is going to be used
as a movable object or the source of a deltaPNG.  Therefore it has to store
much more information about the file instead of simply blasting it onto the
canvas like libpng does.

>restore-to-previous was
>specifically mentioned in the discussion as being missing under LC but in WEB

It's worth noting that restore-to-previous is pretty rare.  A couple years ago I
collected all the banner ads I saw over the period of a few months--about
600--and only two used restore-to-previous (and neither of those used it
effectively).

Comment 303

16 years ago
We should use the newsgroup netscape.public.mozilla.performance.size-matters
for most of this talk.

Comment 304

16 years ago
Posted image sample.jng
Browser crashes when viewing JNG file

Comment 305

16 years ago
>>304 

That is bug #196670. A patch has been completed to fix that bug, but Pavlov is
being mighty slow reviewing it (i.e. ignoring it).
See bug #196670 about the JNG problem.  If you have a pre-June-3 Mozilla or
Firebird browser running on Windows 2000 or later, the JNG decoder fails due to
a Microsoft compiler bug.  There is a fix awaiting review, and an "aebrahim"
optimized executable Firebird with the fix is available at pmt.sf.net.

Comment 307

16 years ago
Still no progress, and 1.5 is nearing RC status.

We need some rogue CVS user who actually cares about 578 votes to check this
back in to the trunk when nobody is looking...

Comment 308

16 years ago
Unfortunately, it would take a rogue CVS user with CVS write access, so most of
us are probably out. However, given that Mitchell Baker mentioned that Mozilla
would focus on "improvements in performance, stability, standards support and
Web compatibility" recently (http://lwn.net/Articles/47298/), there still might
be hope..
That would be OK as long as the "rogue" is qualified and volunteers to take
on maintaining the libpr0n and configuration portion of MNG support.  Libmng
is already taken care of.

Due to some minor bit rot, the "reversal of mng removal" patch needs a little
work before anyone can check it in.  Attempting to use the patch as is, against
the current CVS, results in rejections for allmakefiles.sh, configure.in,
config/module2dir.pl, and build/unix/modules.mk.  It appears that manually
updating these files is fairly straightforward and simple, except for
config/module2dir.pl which as far as I can tell no longer contains the list
of directories that would need to be changed to support MNG.  "configure"
would also need to be updated via autoconf, after patching configure.in.
No longer blocks: 156450
Re: comment #304: the Windows XPI for MNG has been updated to fix the JNG crash
problem.  See bug #196670 comment #43 for details.

Comment 311

16 years ago
Congratulations, mozilla.org team! Now over 600 votes are falling on your deaf ears.

We couldn't have done it without pavlov, who has gone far, far out of his way to
avoid anything MNG-related (the crash-causing bug 196670 went unapproved for
months on his watch), asa, who considers MNG lowest of all low priorities
despite it having the most votes EVER on Bugzilla (
http://forums.mozillazine.org/viewtopic.php?t=16653&start=17 ), and everyone
else who is pitching in on Operation Ignore.

It's good to know that the top guys at the Mozilla Foundation still care about
the community!

Updated

16 years ago
Blocks: 188116
It is pretty funny that this bug has more votes than there were MNG images on 
the Web while Mozilla supported MNG...

Comment 313

16 years ago
Of course you won't find many MNG images on the web, simply because almost 
nobody could see them with their browser. That's not the point. The same can be 
said of CSS3, but that didn't stop you from implementing this "bloat" (and 
rightly so). 
 
There ARE companies that have standardized internally on Mozilla/Netscape 
because of MNG support (see the comments in this bug). These companies use MNGs 
in their intranet and thus need a browser that supports them. Naturally, the 
browser used to browse the intranet is also used to browse the internet, thus 
increasing Mozilla marketshare. 
 
And MNG images on the web won't increase if browser support for this image 
format decreases (d'uh!). 
 
So when do we see the patch from you, Ian, to remove CSS2/2.1/3 support from 
Mozilla because almost no web sites use it? Or is this a different issue? Maybe 
because you are involved in creating these standards? 
 
And while we're at it, why not remove this silly voting thing from bugzilla. 
It's pretty obvious that it serves no purpose as votes only have a meaning when 
developers agree. 
Maybe before you fly off the handle at me, you should check your facts. I'm in 
the pro-MNG group. That doesn't mean that I can't find it funny that there are 
still more people voting for this bug than there are MNGs on the Web.


> Of course you won't find many MNG images on the web, simply because almost 
> nobody could see them with their browser.

That hasn't stopped the proliferation of SVGs, or TIFFs, or any number of other 
formats for which no Web browser has native support.


> That's not the point. The same can be said of CSS3, but that didn't stop you 
> from implementing this "bloat" (and rightly so). 

Actually, we have very little CSS3 support, and what little we do have, is in 
much wider use than MNG.

 
> There ARE companies that have standardized internally on Mozilla/Netscape 
> because of MNG support (see the comments in this bug).

I couldn't find the comments you referred to.


> These companies use MNGs in their intranet and thus need a browser that 
> supports them. Naturally, the browser used to browse the intranet is also used 
> to browse the internet, thus increasing Mozilla marketshare. 

Nothing is stopping such companies building their own Mozilla with MNG support, 
or using the XPI that has been made available.

 
> And MNG images on the web won't increase if browser support for this image 
> format decreases (d'uh!). 

MNG images on the Web didn't particularily increase while support was increasing 
either. Almost all the MNG images on the Web are either testcases, or 
demonstrations of the MNG spec.

 
> And while we're at it, why not remove this silly voting thing from bugzilla. 
> It's pretty obvious that it serves no purpose as votes only have a meaning 
> when developers agree. 

Voting reduces the number of redundant comments in the bugs themselves, which 
makes bugs more likely to be fixed, since bugs with more comments are less 
likely to be fixed since they are harder to read through.

However, you are completely right that the developers that you are not paying do 
not care what you think. They are mostly doing this in their free time. If you 
want an MNG-enabled build, why don't you download the source, add MNG support, 
and distribute the binaries you create? This is how Free Software works -- you 
are free to do what you like.

Comment 315

16 years ago
we (the opensource community) simply need the support of a better animation format than GIF

I was waiting to use MNG in my own website. I was waiting a good gimp support, some better linux 
tools to edit animation,  things like that.   I never expected mozilla to drop a royalty-free format.

why did you remove that ?  because it's "bloat" ?  I think it was good bloat if you care my opinion. 
it's a good thing to support a format like mng

about use, of course mostly noone used mng,  mozilla is for the moment a minor browser, the 
major one is IE and IE doesn't support MNG , but with time, mozilla was a good tool to promote 
MNG
like it promote PNG

I read you can add an xpi or to compile a new binary of mozilla with whatever features I want 
(mathml, good svg, and so on )  but USERS ?  I don't care about myself,  I care about "users" which 
can read my own web-sites.

I need they can have EASILY a good featured browser , I need an easy tool and world-known to 
promote open format.   With things like Alpha channel png, with good animation, with (I hope one 
day) good vectorized animation (svg)  it's easy to convince people mozilla is better

easy to convince developpers,  easy to convince users (with a beautiful website using new formats)

Mozilla is ONE way to promote MNG,  when mozilla remove it, it says to everyone "mng is a failure" 
and no one will want to add it to gimp or kde programs or whatever.

SVG is used not because of mozilla, but because the community NEED a vectorial format to do tools 
like illustrator ,  think about Sodipodi or Sketch (and others) ,  of course, it would be great than ALL 
official mozilla build have svg features,  we could add some svg graphics to webpages and it would 
be efficient to promote  svg tools (adobe commercial ones or opensource ones).

But svg is not like MNG, svg is pushed by adobe and w3c, it helps.   mng need some helps.  mng 
need mozilla.  

mozilla is not only a group of developpers which don't care about users,   it's about a web-browser 
with respect for standards , a webbrowser for developpers, web-developpers ,designers AND 
_users_.  and, I really don't think ALL "mozilla developpers" don't care about people's opinion,  it's 
not what  I understood when I spoke month ago with some mozilla and netscape (at the time) 
people.

please reconsider your opinion.

Comment 316

16 years ago
Alright... Before this bug flies off the handle again with pro-MNG and anti-MNG
posts that add to an already difficult to read through advocacy bug...
(1) Personal Attacks aren't going to get anybody anywhere... usually they're
only likely to further isolate the person you're attacking from the cause you
want them either to embrace or stop blocking.
(2) MNG was removed.... the reasons at this point... don't seem to matter much
anymore.. Basically, it was opinions of code bloat.. which were used
unilaterally against some parts of the code.. and the lack of a maintainer for
the glue code for MNG as part of libimg2... The latter still lacks a maintainer
which seems to have stalled any progress as part of bug 204520.

So, before a second bunch of ranting starts.. try reading through this bug and
Bug 204520.. ;-)

-- Wolf

Comment 317

16 years ago
At this point, it seems clear to me that restoring MNG is the only way to stop
the ranting.

Comment 318

16 years ago
Yes, implement my feature request or I shall taunt you a second time!

Has it really come to that? Will someone start drowning a baby kitten each day
that MNG remains disabled?

Removing myself from the CC list, since the removal of MNG from Mozilla hasn't
really made life that much worse for me. However, listening to your diurnal
whining has.

Perhaps some of you should take this as a hint. And a chance to reflect. I can
assure you life will continue as unplanned without MNG support in this
particular browser. I encourage you to remove your votes on this bug as a simple
show of support for rationality. (not that implementing MNG is irrational, but
the fact that there are three-hundred and eighteen comments here is).

Oh, also: bugzilla is not a discussion forum. (cf. netscape.public.mozilla.*)

Comment 319

16 years ago
See 222099.

Comment 320

16 years ago
In reply to comment #318

This is not about implementing a feature request. This is about restoring
functionality that Mozilla used to have and for which there is no replacement.
MNG support was one of the features that brought me to start using Mozilla.
Others have cited MNG as a requirement for Mozilla theme developers to make
themes that don't look like ****.

MNG is a stable, open, free standard that Mozilla has working code for. There
are hundreds of people who use MNG or are interested in using MNG, and thousands
more who don't know what they're missing and will become as angry as the rest of
us when decent MNG editors are developed.

If rationality were in charge, MNG would never have been dropped from Mozilla in
the first place or it would have been restored after the file size issues were
solved. Instead, we have a egotistic self-centered clique refusing to admit they
may have made a mistake and making the Mozilla project and community suffer for
their errors. This is hardly rational behavior that you are supporting!

Dropping votes for this bug will do nothing to enourage the Mozilla developers
to restore MNG support. Voting is a simple way to show that there actually is
community support for the MNG format. I want to see more votes for this bug so
it continues to stand out as a shining example of bad management practices.
Comment # 318 says: "I encourage you to remove your votes on this bug
as a simple show of support for rationality."

OK, removing mine.  It might be fun to rock the boat a little.  Let's
put them all (temporarily at least) on bug #196670 which is blocking
this one, has been r'ed and sr'ed and is just awaiting "approval", to
work around the JNG crash that is due to a Microsoft compiler bug.

Comment 322

16 years ago
Well, 1.5 has been released, no merging in of MNG - not to mention the patches
to reduce bloat/redundancy/crashes.

I guess I'm going to have to rip out all the lovely JNG images on my website.
Sure was nice to have complex images that looked great on any background, and
could overlay stuff as well.

However,  while I was able to convince those people using my site to stay with
1.4 for time being, most of 'em will want to update to 1.5.

Unless someone here has the bandwidth and desire to put a mirror out for a
patched version?  Could link my friends to that.
I could also add the patches to the Gentoo ebuild that will be coming out - try
and convince the Gentoo maintainers to use them as well.

Updated

16 years ago
Flags: blocking1.5+
only drivers can set blocking.  If you're not a driver, please don't.
(not to mention it's too late to block 1.5 anymore anyway)
Flags: blocking1.5+
Recall that in comment #200, drivers approved restoring MNG support.  This
approval had two parts:

  1) They invite MNG support to be put back in the image library as a 
     configurable option that is turned off in default
     mozilla.org-produced builds (Seamonkey, Firebird,  Thunderbird).

The only thing preventing this from happening is the lack of a qualified
volunteer to do it!  If you are able, please volunteer.  I will help you
do the work.  Your first task (easy) will be to check in the tiny patch that
fixes bug #196670.

  2) They are interested in having only MNG-VLC supported as a configurable 
     that does not entail all the footprint of full MNG, and would support 
     such a subset being turned on in mozilla.org-produced builds and made 
     part of the "typical" GRE configuration that Mozilla.org brands and     
     promotes

In subsequent discussion it became evident that MNG-VLC would not be useable,
and we didn't come to a conclusion about what larger subset of MNG would be
OK.  I don't see any point in resurrecting that discussion right now; let's
find the volunteer and get part 1 done first, using the MNG_BUILD_FULL_MNG
configuration of libmng-1.0.6.

I expect that libmng-1.0.6 will be released at the end of this week.
libmng-1.0.6beta1 has been out for a month and no bugs have been reported
against it.
Comment #322 asks: "Unless someone here has the bandwidth and desire to put a
mirror out for a patched version?"

I have both.  The bandwidth is at mngzilla.sf.net, project just initialized
today to develop the MNG-restoration patch and to host MNG-enabled binaries. 

Comment 326

16 years ago
I can build Windows binaries of the releases.

Comment 327

16 years ago
I can provide Linux builds. 

Comment 328

16 years ago
Then, let's rock! I want to be able to upgrade to 1.5, but don't want to lose MNG.

Good to see some cooperation and helpful ideas!

Comment 329

16 years ago
Hopefully we'll have a project space forum to comment in shortly, but I
volunteer to create the Gentoo ebuild.
Should be fairly trivial.  Just the 1.5 ebuild and appropriate patches, plus a
build flag.
Will ask the Gentoo developers if MNG can be default build flag, with -MNG to
explicitly disable.
Also.  Camino, anyone?

And we should check out fedora.redhat.com to see about mozilla+mng being
incorporated into Redhat distro.

How about Debian.  Any debian package builders here?

Comment 330

16 years ago
If I understand it correctly, I just apply the last three patches in this bug to
the 1.5 sources in order to get what we want here right?

Comment 331

16 years ago
Re: patches in comment #330, see http://mngzilla.sf.net

Updated

16 years ago
No longer blocks: 8415

Comment 332

16 years ago
Is chrome now able to use MNG's? If not, why the removal of blocking bug 8415?
I removed "or MNG" from the summary of bug #8415 because that part was currently
invalid.  Perhaps someone will open a new bug that says animated chrome should
use MNG, which depends on this bug.

Comment 334

16 years ago
>Comment #322 asks: "Unless someone here has the bandwidth and desire to put a
>mirror out for a patched version?"
>
>I have both.  The bandwidth is at mngzilla.sf.net, project just initialized
>today to develop the MNG-restoration patch and to host MNG-enabled binaries. 

Have just built a Firebird, based off trunk checked out earlier today, with MNG
support built-in.  Used the reversal patch and information from MNGZilla
(comment 331) and applied the changes by hand, as the patch makes me uneasy
because it's outdated.  It's affected by bug 196670 "JNG crashes Win32 builds"
but displays MNG images adequately.

http://forums.mozillazine.org/viewtopic.php?t=32282

Currently hosted on my little webspace.  I wouldn't mirror that build yet,
(unless you need a Firebird build mirrored) as this build was simply an
experimental to see if the patching would work.  I compile a SVG-DOMi-Venkman
build on a daily basis, and will probably introduce MNG to my daily Firebird
build.  Future builds of mine will most likely be found on the MozillaZine
Firebird Builds forum.  (My username is "MadmanNova".)  If you wait until
tomorrow or later this week, you'll see a MNG-SVG-DOMi-Venkman build.  At that
point, I think it would be a-okay to mirror.

http://forums.mozillazine.org/viewforum.php?f=23

Comment 335

16 years ago
Did the MNG removal reversal patch on a freshly checked out tree and diffed to
get a newer version of the patch.  (Some of the older patch was outdated.)

Caveat:  This tree is off of the SVG_20020806_BRANCH, however.	The files that
may be affected are configure.in and config/autoconf.mk.in.

Currently trying a new build, having taken these steps:
Checkout SVG_20020806_BRANCH for Firebird, with SVG(libart).
Applied diffs in new patch.  (Well, I modified by hand, and then diffed.)
Put copies modules/libimg/mng and modules/libpr0n/decoders/mng into the tree. 
(From mngzilla site.)
Run autoconf to re-do configure.
Build.

Glenn:	I've applied your modifications to libmng_chunk_io.c for this build.

I'll report back later tonight with results.  I've been having trouble building
anything today with the plethora of new checkins, so I decided to go for a
fresh tree.  Hopefully the build problems I've been having were ironed out.

Updated

16 years ago
Attachment #134523 - Attachment description: Updated removal reversal patch → Updated removal reversal patch (using svg branch)
Attachment #134523 - Attachment filename: mngpatch.diff → mngpatch-svg.diff

Comment 336

16 years ago
Really sorry about the bugspam.

Apparantly, something in a recent checkin was killing my SVG builds, so I had
to checkout a new tree.  So I went and re-did the entire tree and checked the
patch information again.  (It wasn't broken--something else was--but I still
wanted to make sure I fixed it.)

A newer Firebird MNG-only build will be up soon, provided nothing else is
broken in the trunk.

I'm also using the MNGZilla method of implementing MNG by simply overwriting
the directories with a MNG-capable version of the files.  However, doing this
with the trunk--especially at a time like this when the 1.6b checkin window is
open--is difficult because they change rather quickly.	My proposed method of
getting a build like this with little effort is to:

Use MNG patch (like the one I have), provided it's recent (close enough to
current code tree).
Copy (unzip?) the [modules/libimg/mng] and [modules/libpr0n/decoders/mng]
directories to the code tree.
Run autoconf (or "bash autoconf" from DOS) in the top source directory to
reconfigure the configure file.
You _should_ be able to build properly after this.

Checkouts with updates to any of the configuration stuff
(build,autoconf,configure) may (and probably will) cause problems, though.  The
configure file can't be edited manually and still work.  It's seriously
impossible.  And using a pre-configured configure file (like from the MNGZilla
CVS) won't work with basically anything much recent than the tree it was
created from.

I was having trouble with the MNGZilla provided files (from CVS) and
overwriting everything the way I was supposed to, and I didn't realize about
the configure until after a while.  Wasn't in the documentation or anything
(that I noticed) so I toyed around with it for a while before figuring it out. 
Just a few words to anyone out there who wishes to build as well.

Comment 337

16 years ago
New Firebird build up, with a fix that Glenn sent me that appears to have fixed
bug 196670.

http://forums.mozillazine.org/viewtopic.php?t=32282

A very very happy success, IMO.
Re: comment #337: Nova's Firebird with MNG support and JNG fixed, built
for Windows 2000+, is at
https://sourceforge.net/project/showfiles.php?group_id=92539
I've verified (on a FreeBSD platform) that Nova's "trunk" patch will
successfully and simply add MNG capability to Mozilla-1.6a.  I've combined the
patch with the set of libimg/mng and libpr0n/decoders/mng files that need to be
restored, and a README.txt, into a SourceForge distribution file (choose one of
tar.gz, tar.bz2, or zip) at
https://sourceforge.net/project/showfiles.php?group_id=92539
The fix for bug #196670 has been applied to this distribution.

Comment 340

16 years ago
Firebird 0.7 (Release Version) with MNG enabled:

http://forums.mozillazine.org/viewtopic.php?t=33650

Built with MSVC 7.0, dynamic build.  Compatible:
Win 95(?;unlikely)
Win 98(?)
Win ME(?)
Win 2000
Win XP

I don't intend on announcing anymore builds here, unless they are release
versions, or if they are for platforms that currently don't have it.

Comment 341

16 years ago
  2 Votes for Bug 195280 - Removal of MNG/JNG support
614 Votes for Bug 18574  - restore support for MNG animation format and JNG
image format

Shouldn't Mozilla be a democratic product and not a monarchic one?
Greetings from Micro$oft ...

MNG & JNG have to be supported by default otherwise the development
of the World Wide Web will suffer.
Alex, i find your comment highly offensive. Are you claiming that Sweden is not
a democracy just because it's a monarcy? This is like a slap in the face on our
king Carl XVI Gustaf and the entire swedish monarchy. I expect an immidiate
appology or we will have an international incidnent on our hands.

Or is this another way that the germans are insulting our royal family. Last
time it was through "Woche der Frau" and this time it's through bugzilla.

/ Jonas Sicking, for democracy and proud to have a king!

Comment 343

16 years ago
Jonas: Bugzilla is no place for personal attacks. Please abstain yourself in the
future from making such comments, and don't relate in your posts the other
people's nationality and extrapolate based on that.

Alex: please read http://www.mozilla.org/mission.html , the "Benevolent
Dictator" section. In the future, please respect the development model that
Mozilla already selected (a module-owner/drivers driven process, not a
democratic one).
Discussion of governance is off topic; please end this thread now.
What we need is a qualified person to step up and offer to maintain
the MNG-related code in modules/libpr0n, which comprises less than
1000 lines.
I agree, being from the Goat Kingdom, I can tell you that a monarchy rocks!  You
get to sniff female goat behinds without being hanged!

Now dictatorships, those suck.

And sicking was helping to find a new owner - he set straight that mozilla
doesn't care what government your country has.  This allows the millions of
developers who come from monarchies to feel confident and not oppressed and thus
consider taking over MNG ownership!

Comment 346

16 years ago
Wait wait wait... I thought the Zillanians live in a dictatorship (bugzilla the
kaiser, new contributors the slave with no rights to change their own bug
reports) ... do Zillanians live in a monarchy, dictatorship, hampa-pampa-banana
repulic (like current germany and the US under King Bush II) or what? :))))

Comment 347

16 years ago
People, please this has nothing to do with the bug in question so please 
refrain from posting that pointless drivel to the buglist.

Thank you.

Comment 348

16 years ago
Jonas: If a monarch decides against the will of the folk it is bad, nothing more
I wanted to say. And don't correlate the Top Level Domain of my address to my 
origin, that's wrong.

Vlad: Have you read the "Benevolent Dictator"-section?
Aren't 613 votes - the highest number of votes for any "bug" in Bugzilla -
against the removal enough to say that tor is not doing a good job here?
If it's not a democratic process, why do we have to discuss here?
Alex: What? You're now blatantly critizing our form of goverment as well as
calling our monarch a dictator! Fear the wrath of the swedes, it will be
Ragnarok all over again.

So you're saying that you're not german? Please tell where you're from so that i
can properly direct my insults.

/ Jonas Sicking, Swedish and proud of it.

Comment 350

16 years ago
Re: comment 348

You are supposed to discuss things relative to the bug, such as an idea on how
to implement it or something an implementer might miss.

If you are willing to maintain the relevant code, volunteer yourself or find
someone who will.  Module owners are not forbidding you from volunteering for this.

Comment 351

16 years ago
Please stop spamming this bug! There are 120 people subscribed to this bug.
Spamming the bug not only delivers useless messages to these people's mailboxes,
but also makes the bug very hard to read, because for each comment you have to
evaluate whether it's relevant discussion or irrelevant prattle. You have
already been chided once. Now please behave or i'll have to tell your respective
moms.

Comment 352

16 years ago
I would /really really/ appreciate if you guys took this to private messages or
even stopped this altogether.

Glenn: cannot any of you guys do that?  Seeing that there was like three or four
of you who worked or are working on making the MNG/JNG library small enough,
can't any of you take up the maintenance of this bit of code?  I myself am near
internet access most of the time (thus, too, available pretty often), and would
love to help, alas I lack enough programming knowledge (and AAMF Mozilla source
knowledge) to be of any help here.

Comment 353

16 years ago
> You are supposed to discuss th