Closed Bug 18574 (mng) Opened 25 years ago Closed 18 years ago

restore support for MNG animation format and JNG image format

Categories

(Core :: Graphics: ImageLib, enhancement, P3)

Product:
Core
Component:
Graphics: ImageLib
Type:
enhancement

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: martin, Assigned: opi)

References

(
URL
)

Details

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

Attachments

(6 files, 57 obsolete files)

MNG testcase
84.14 KB, video/x-mng
Details
comment 85 - linux XPIs
182.11 KB, application/zip
Details
comment 85 - OSX and OS/2
254.57 KB, application/zip
Details
comment 85 - solaris/sparc 2.7 and 2.8
263.07 KB, application/zip
Details
comment 85 - windows
91.31 KB, application/x-xpinstall
Details
sample.jng
4.31 KB, image/x-jng
Details
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.
Assignee: pnunn → newt
Reassigning to PNG component owner, Greg.
Is MNG a finalised standard yet?
Status: NEW → ASSIGNED
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].
Keywords: helpwanted
Per e-mail from Greg, he has relinquished PNG component ownership; thus, reassigning assigned bugs to ImageLib owner.
Assignee: newt → pnunn
Status: ASSIGNED → NEW
Reassigning to nobody@mozilla.org, for anyone who'd like to implement this to pick up.
Assignee: pnunn → nobody
Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed thru.
Assignee: nobody → leger
Summary: [HELP WANTED]are there plans to implement MNG (Animated PNG images)? → are there plans to implement MNG (Animated PNG images)?
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/
URL: http://artpacks.acid.org/pub/mng/
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 ;)
Updating URL, removing "helpwanted", and taking bug.
Assignee: nobody → tor
URL: http://artpacks.acid.org/pub/mng/ → http://www.libpng.org/pub/mng/
Keywords: helpwanted
Status: NEW → ASSIGNED
tor rocks!
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.
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
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
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.
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
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.
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
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.
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
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
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.
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
tor: This is Great! I can't wait to play with this... -P
[#whatever pnunn said!]
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.
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.
Copy/paste/modify error on my part - patch checked in. Thanks!
Blocks: 8415
Depends on: 43684
Summary: are there plans to implement MNG (Animated PNG images)? → MNG tracking bug
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
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
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.
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
I don't know of any mac-specific problems other than the gamma correction, which affects mac more than other platforms.
QA Contact: elig → tpreston
*** Bug 66963 has been marked as a duplicate of this bug. ***
Blocks: 66967
Keywords: meta
Depends on: 66976
Blocks: 66979
No longer blocks: 66967
MNG support does not appear to work in Build 20010430 Win98. Is anyone else experiencing this problem?
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
Image library name discussion --> bug 66984
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
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
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
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
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
Yes, and only @netscape.com should be setting nsbeta1(+|-).
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?
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
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
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.
Blocks: 104166
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
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
Closed: 23 years ago
Resolution: --- → FIXED
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
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
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
Reassigning since the bug is currently assiged to the person who CAUSED this bug.
Assignee: tor → randeg
Status: REOPENED → NEW
Attached 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.
This bug has 30 CCs and 39 votes. 50 of either will make this bug block bug 163993.
Attached video MNG testcase —
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.
Blocks: majorbugs
Removing MNG saved what, 300kb on my 40+ GB drive? Whoop-de-doo!
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).
Severity: enhancement → major
Attached 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.
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... ;-( ).
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
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
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
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.
Blocks: 44866
No longer depends on: 44866
Will help where I can, but I've no experience with graphics.
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.
Attached file comment 85 - windows —
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
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
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.
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.
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.
It's only been removed on the trunk not the branch
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...
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.
Please put it back into the build. As someone stated before. NO PATENT ISSUES with this format.
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
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?
The same question has been nagging me but I've been hesitant to ask it: at what point are the votes important?
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.
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.
Amusingly, bug 195280 has *lost* votes. I believe it had 2. Now 1. Could be because it was "fixed" I suppose.
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.
>> 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.
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.
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.
> 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.
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."
**** 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.
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
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>
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.
<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
Flags: blocking1.4?
Flags: blocking1.4?
Flags: blocking1.4-
Setting blocking1.4- as MNG suppport has not been removed from the 1.4 branch and thus will be in 1.4 final.
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*
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.
Flags: blocking1.4- → blocking1.4+
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...
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.
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.
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
------- 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
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.
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.
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
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.
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
Don't think I'm going anywhere. Remember, I was working on Mozilla well before I started at Netscape ;)
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.
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...
"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.
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.
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!
trusted2mozilla.org@slater.ch please take your bugspam elsewhere, thanks
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.
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?
Skewer: Let's see how did you put it . . oh yea "please take your political- spam somewhere else please, thanks."
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.
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
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?
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
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.....
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 :)
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.
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
Updating dependancy tree, removing duplicates and putting bugs they are duplicated to.
Blocks: 156450
No longer blocks: 198591
Depends on: 41333
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+
Flags: blocking1.5b+
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.
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.
Flags: blocking1.5b?
Flags: blocking1.5b-
Flags: blocking1.4.x-
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?
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.
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!
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.
(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.
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?
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
So, essentially, the current status quo is preserved. Is anyone surprised?
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.
Is that a tentative "yippee" then? What's "VLC"?
Could you please explain the difference between "full" MNG and MNG-VLC? Thank you.
"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.
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 [...]"
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.
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.
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.
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?
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.
> 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.
>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?
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.
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
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.
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...)
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.
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!
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.
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.
Glenn has already added such support. See the bug listed in Whiteboard Status.
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".
"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).
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?
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
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.
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?
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...
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"!
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.
"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**.
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 ? ;-)
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.
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
> 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.
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
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.
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. :)
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.
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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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!
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.
"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.
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).
We should use the newsgroup netscape.public.mozilla.performance.size-matters for most of this talk.
Attached image sample.jng —
Browser crashes when viewing JNG file
>>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.
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...
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.
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!
Blocks: 188116
It is pretty funny that this bug has more votes than there were MNG images on the Web while Mozilla supported MNG...
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.
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.
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
At this point, it seems clear to me that restoring MNG is the only way to stop the ranting.
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.*)
See 222099.
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.
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.
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.
I can build Windows binaries of the releases.
I can provide Linux builds.
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!
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?
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?
Re: patches in comment #330, see http://mngzilla.sf.net
No longer blocks: 8415
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 #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
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.
Attachment #134523 - Attachment description: Updated removal reversal patch → Updated removal reversal patch (using svg branch)
Attachment #134523 - Attachment filename: mngpatch.diff → mngpatch-svg.diff
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.
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.
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.
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!
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!
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? :))))
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.
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.
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.
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.
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.
> 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. A configureable option for MNG/JNG that is turned off in default is useless, because this will prevent distribution of MNG/JNG in the wild. "640 Kilobytes of computer memory ought to be enough for anybody." - Bill Gates, 1981 "the formats [MNG/JNG] are little used in the wild [...] it's worth considering removal" - tor, 2003
Re: recent comments This bug has inspired me to file bug 225751 . I'll post no more off-topic.
Okay. Re comment #270, is Pavlov acceptable for libpr0n mng code handling? Or was he just volunteering to help reduce the size of the mng decoder used in mozilla? In either case, what'd required for a maintainer? I have quite a bit of C and C++ coding experience, whole projects, and additions to existing projects. I've been doing it for about 10 years now. (Well, 5 years for c++) Does this make me an acceptable maintainer? I'd really like to use MNG-required-for themes, and I agree that there's little chance of MNG ever *becomming* highly used unless Mozilla supports it first. I mean, hell, IE doesn't even have Tabs yet, and pretty much everyone else does (incl. IE-plugins). Why can't this be yet just one more thing mozilla did first, or at least early. And it's not like mozilla's ever likely to be small, I can afford another 100K (or less according to bug#204520) for a decent (ie, useful in the 24-bit world we now live in) replacement for the current low capability of animated GIF's... Anyway. I have all-day internet connectivity, and at least a few hours a week. Let me know what's you guys (drivers) are looking for, and if it's just someone to "own" the code, I volunteer to be initiated. (Why was Glenn refused? I don't remember if it was said...) Thanks.
I second Chris' nomination. Now can someone request review for this patch?
Because of the intensive bugspam here, I'm removing my vote for this bug. Sorry for adding to that bugspam, but I wanted to make the spammers aware that their actions just decrease the chances that this bug ever gets fixed.
Anyone that was going to fix this bug, and then decided not to because of the number of comments attached to it, would be acting childish. If they genuinely preferred to act in that manner, perhaps they would better serve the public by not participating in the project at all.
Mozilla is a great browser. Adding MNG and JNG support will only make it better. MNG and JNG will not disappear. Once more people realize it's uses it will become more mainstream.
Maybe someone has already suggested this, but I do not have time to go through 200 entries, so, I suggest that MNG support be skipped for alpha releases, maybe beta releases, and the nightlies in between, but then added in for release candidates and finals. If the only reason is space, it would help. I also hate to spam this place, but I would also really like to use animations and not pay $500 for Macromedia Flash, just to get a soccer ball to move.
But the idea is to reduce the size of the final product, isn't it?
Maybe in a few years the GIF support could be removed ;-)
Our GIF support library is orders of magnitude smaller than our MNG support library. So that wouldn't help
A new tar distribution of Nova's mng restoration patch, the mng subdirectories, and autoconf'ed "configure" file, is available in the DOWNLOAD area at mngzilla.sf.net for restoring MNG capability to Mozilla-1.6.
For developers trying to do opensource web aplications: Note that if you use gif animations on your app you can't use the savanah soft development facility, because gif are forbbiden on this site. 1-dont do a mozilla compatible app 2-dont use savanah 3-use static images
As a follow-up to comment #355, I again ask drivers, or whoever else "makes the decision(s)", what's needed here. At one point, my understanding was that you needed someone to own and maintain the code. I volunteered to do that, but noone has responded to me with a "yay" or "nay". Please let me/us know what is needed, and if it's only a human to leash to it, I again volunteer. I would like to be able to move forward on this, where "forward" means "MNG support will soon be part of the base distribution again". Adding in patches for my own use is fine, but doesn't solve the larger problem of people not using MNG because there's so little support for them. Thank you.
Just for the record: http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c200 indicates that this will not be a part of the "base distribution" per drivers, even if it is added into the trunk.
It would be a good start to have it bach in the trunk CVS, and be able to try different sub-profiles so that one of those might get into default build again. Chris: You probably should directly mail drivers@mozilla.org as you can't be sure they're closely watching this bug report.
mconnor: Yes, I saw that, but it saddens me. I don't see a point in doing it unless it's going to be in distributed builds. But, they do indicate that a MNG-VLC support could make it back into the "standard" distributions. Most people seem to believe that that would be of no significant use, but if we can get drivers to allow MNG-LC, or even MNG after enough time goes by to overcome their problems with it (since much work has already been done on reducing it's footprint), then it's worth looking at. (*sigh*) Okay. I'll email drivers and volunteer for taking over support, so that it's at least "on-trunk". I presume that the status right now is that it is not on-trunk? From the last "removal reversal patch" here, it looks like it's put into a bunch of the build system stuff, but that the library itself (libimgmng) there must already be code for. Or would it be more desireable to move it into libimg, as seems to have been done for most other formats? That would get the JPEG savings, et al, discussed here...
I guess it's up to discussion with drivers and/or imglib2 (a.k.a. "lipr0n") owners if it should go into libimg or not. Anyways, there's the libpr0n/mng glue code, and owner/maintanership of that seems the big problem (and I guess that's what you're volunteering for), if that's solved, I think all other things can be settled in a email and/or IRC discussion of you, drivers, and libpr0n owner(s). Now would also be a good time to go for that, as there's still some time until 1.7a, and that gives us all plenty of testing time until the next final ships :)
No, that wasn't what I'd intended to volunteer for. I presume that bug #204520, comment #65 still serves as a statement that Pavlov is willing to accept that glue code. It shouldn't be hard to maintain, and Pavlov is certainly qualified. :-) So, anyone else I should include in an email discussion other than drivers? Is there a mailing list for libpr0n people, or should I just include Pavlov?
Chris: The glue code is the part that really _needs_ a new owner, Pavlov doesn't want to have anything to do with it. IIRC, Glenn said he'd be willing to own the libmng code itself. The real problem _is_ the glue code.
this bug enabled developers to start a bottom up clean up of mozilla. i have not been very impressed. i have been rude, but starting size standards with the free stuff is very very revealing. the same sort of revelations lead me to believe much much more in the promise that i see with gtkhtml3 and the, well, for lack of a better word, sweet developers there. by the way, did you see the scene in the pirate movie where the one savvy pirate was riding the sinking ship into the bay and stepped on the pier. i guess this would be andersca. that was at the beginning of a good movie written by a corporation. this has been a very very bad one. more like "i love you to death" which was great and funny yet sad. i like movies that are funny and funnier. you need free and good software for that. i guess good and free hardware also, as this is all i can afford. losers. it is not that i am calling mozilla losers, not in the slightest. Even if the hippest of the coders got the hell out when they smelled it happening. for shame, all of you that started to diet with the free stuff. given a chance, i would like to discuss it with your moms. also, thank you for the best browser available. a corporation should not start with the free stuff to diet. simply. did you read the same stuff about growing up right that i did? at the same time, i use Mozilla as a WYSIWYG and it is a little too forgiving. is there a bug about that? carol
Attached file Full MNG (1.0.5) patch (trunk) bzip2 (obsolete) —
This is the full patch. The missing files are included in this patch, it is against trunk (after landing SVG). MNG doesn't compile by default with this patch, you need: --enable-image-decoders=default,mng to build MNG in your patched tree. @Glenn Can I assign this bug to me? @Pavlov I would Maintain the MNG clue code, I will have it back in trunk without enabled by default. What must I do?
Attachment #9985 - Attachment is obsolete: true
Attachment #10226 - Attachment is obsolete: true
Attachment #124876 - Attachment is obsolete: true
Attachment #134523 - Attachment is obsolete: true
Attachment #134552 - Attachment is obsolete: true
Sure, take it. Glenn
Assignee: glennrp → opi
A Free program (for windows) called SlowView, will view, make, and batch convert MNG images. http://www.slowview.at/ it is at RC2 right now (and has been for months) for anyone interested in a really good MNG maker program. it is not opensource, but it is freeware. it is less than a megabyte (not including required software (http://www.slowview.at/?page=requirements)
Blocks: 121927
(In reply to comment #376) > A Free program (for windows) called SlowView, will view, make, and batch convert > MNG images. How is this relevant? Don't spam bug reports.
Alexander, maybe you should ask Pavlov for review/superreview/approval of your patch. I think that the best thing would be to contact him personally and to make sure that you are heading in the right direction. Maybe this could be a feature that can be enabled/disabled in the installer (like Domi and Venkman can already be switched on/off in the Firefox windows installer), or as you are already aiming at, make it an optional compile switch. In any way, either contact Pavlov personally (I am not sure if he is still looking at this spammed "thread") or set the review flag for your patch. TNX for offering to maintain the glue code.
Thanks, Alexander. The patch id=140905 wfm on FreeBSD 5.0 Be sure to use the "-p0" patch option, and remember to run autoconf afterwards. Glenn
Sorry for the spam, but: I keep getting mails on this bug (which is fine) containing all changes since Feb 08 (which is not). Does anyone else experience this? It only happens with this bug. Stefan
(In reply to comment #380) > Sorry for the spam, but: > I keep getting mails on this bug (which is fine) containing all changes since > Feb 08 (which is not). Does anyone else experience this? > It only happens with this bug. > Stefan same here
Hate to do this, but, well: "Me too." (re: two above comments)
Sorry for the spam: Per comment 380 and further: this is bugzilla bug 234159. Please file further comments on repeated text in bugmail in that bug.
Comment on attachment 134552 [details] [diff] [review] Updated removal reversal patch (mozilla-1.6) Removed "obsolete" flag because this patch is still good for updating mozilla-1.6.
Attachment #134552 - Attachment description: Updated removal reversal patch (trunk) → Updated removal reversal patch (mozilla-1.6)
Attachment #134552 - Attachment is obsolete: false
This patch replaces opi's recent "Full MNG" patch. It brings the libmng files up to the current libmng CVS (version 1.0.6+), and makes it possible to configure mozilla without libpng, thus using libmng to provide PNG support. This patch is to be used with the current Mozilla trunk.
Attachment #140905 - Attachment is obsolete: true
Comment on attachment 141710 [details] Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip) corrected MIME type
Attachment #141710 - Attachment description: Full MNG-1.0.6+ restoration to Mozilla-1.7a → Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip)
Comment on attachment 141710 [details] Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip) Corrected MIME type, removed patch tag, so that the file is handled properly. P.S. I'd rather see it as a regular diff.
Attachment #141710 - Attachment is patch: false
Attachment #141710 - Attachment mime type: text/plain → application/x-gzip
Comment on attachment 141710 [details] Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip) Changed MIME Type
Attachment #141710 - Attachment is patch: true
Attachment #141710 - Attachment mime type: application/x-gzip → text/plain
Comment on attachment 141710 [details] Full MNG-1.0.6+ restoration to Mozilla-1.7a (gzip) Corrected MIME type again (Robert broke my previous change :-( ), removed patch tag, so that the file is handled properly.
Attachment #141710 - Attachment is patch: false
Attachment #141710 - Attachment mime type: text/plain → application/x-gzip
Sorry. Strange. Bugzilla should have given me a collision notice. But I didn't get anything. Also put the wrong mimetype by accident. To bed with me. Sleepy a must.
(In reply to comment #390) > Strange. Bugzilla should have given me a collision notice. But I didn't get > anything. Also put the wrong mimetype by accident. To bed with me. Sleepy a must. It is strange... Nor did I got a message that I changed the attributes. Don't worry about yourself --- you probably put some reasonable MIME type, but you surely did left the patch tag, which caused the type to be changed back to text/plain. See the bug activity on this bug for details on the full picture.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
The latest and greatest Patch for MNG This patch replaces glenn's recent "Full MNG" patch. + updates against cvs trunk + bugfix of bug #121927 Missing: Configure the MNGBUILD (at the moment it compiles MNG_BUILD_FULL_MNG (or _RAW_MNG don't know yet) but MNG_BUILD_MOZ_MNG should be enough ... drivers requested MNG_BUILD_VLC
Attachment #141710 - Attachment is obsolete: true
Drivers withdrew the request for MNG_BUILD_VLC (see comment #257). Instead, a minimal useful build is MNG_BUILD_WEB_NO_JNG. If you build this, without "png" in the decoders list so that libmng handles png decoding, the library size increase is about 70k.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
This patch is untested ... excuse that I hadn't the time yet. But I hope it works well. Define MNG_TYPE with --enable-mng-type= Default is MNG_BUILD_WEB_NO_JNG TODO: Update to latest libmng CVS Wait for libmng 1.0.8 (should be around 1.7 freeze) to go into 1.8a
Attachment #142326 - Attachment is obsolete: true
Attachment #142804 - Attachment is patch: false
Attachment #142804 - Attachment mime type: text/plain → application/x-bzip2
Alexander, why don't you ask someone to review the patch?
Cause I must test it for my self (and maybe Glenn also test the patches before), then I have points on my todo list and then I must speak with tor/stuart before it have sense to ask for reviewing it. And I don't want to spam the libimg/libpr0n developers ... they are not very happy with such thinks.
Patch #142804 works fine and builds a MNG/JNG-enabled mozilla, when applied to a fresh checkout from this morning's trunk of cvs. However, the build-type seems to have no effect, and MNG_BUILD_FULL_MNG is always built. There is an extra space at the end of line 75393 of the patch, but removing it doesn't help.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
+ Updated all libmng files to latest in CVS + Fixed --enable-mng-type so that it work TODO: - Waiting for libmng 1.0.7 (and not 1.0.8 as I'd sayd it last time)
Attachment #142804 - Attachment is obsolete: true
Has anyone talked with drivers if they are actually interested in full MNG turned back on. I know they approved VLC when it was throught to be a gif replacement, but the fact that it isn't doesn't mean that ful MNG is automatically approved AFAIK. Also, has the two reasons that MNG was backed out been addressed? I.e. lack of ownership (gluecode as well as libmng) and the fact that MNG in mozilla had some bugs (crashes and wrong notifications sent IIRC). In order to take ownership of a module in mozilla quite a lot of mozilla experience is usually requested, so you might want to clear any proposed owner with drivers if you want it turned on by default. Thirdly, i've read recent comments about using libmng to decode PNG images. I didn't think that was an option given that it couldn't do progressive rendering, hadn't gotten as much testing as libpng among other things. I'm not against including MNG support in mozilla at all, quite the opposite. However I'd hate to see a lot of effort being wasted before the correct issues has been addressed. Also, i'm not a driver, so don't talk with me about any concerns you have, I can't do anything that the next guy can't. Nor is this bug the appropriate forum for discussing these things. I'm sure that everyone involved knows who to talk about these things with, and where to do that.
Patch #142953 needs a slight correction. We are not using libmng_conf.h exactly as found in CVS. Change #ifdef MNG_MOZILLA_CFG #include "special\mozcfg\mozlibmngconf.h" #endif to #include "mozlibmngconf.h" Once this change was made, it worked for me and I was able to build MNG_BUILD_MOZ_MNG and MNG_BUILD_WEB_NO_JNG and other configurations. > Has anyone talked with drivers if they are actually interested in full MNG > turned back on. I know they approved VLC when it was throught to be a gif > replacement, but the fact that it isn't doesn't mean that ful MNG is > automatically approved AFAIK. Drivers said we could put full MNG back in as a configurable, default OFF. That was nearly 7 months ago (see comment #200). There was also unresolved discussion about putting some subset of MNG in, default ON. MNG-VLC isn't capable enough, and the minimal MNG_WEB_NO_JNG is probably too big. The only thing preventing putting full MNG on the trunk, default OFF, right now, is the lack of an acceptable volunteer.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
There was a little data corruption on my harddrive so that my last patch missed 2 updated files :-( + update libmng_conf.h and MOZCHANGES in the diff to my tree @sicking What bugs do you mean? The latest for ma known crasher bug is resolved in this patch (As resolved in libmng 1.0.6) ... also the looping bug is resolved in our glue code. So I've nothing outstanding as far as I see.
Attachment #142953 - Attachment is obsolete: true
A few problems with the decoder, off the top of my head: * doesn't fire OnStop{Decode,Container,Frame} * you might want to see if necko now has the features that would let you decode without buffering the whole stream * decoder will crash if it runs of memory in said buffering (along with a number of other unchecked allocations)
Re: comment #402 > * doesn't fire OnStop{Decode,Container,Frame} > > * you might want to see if necko now has the features that would let > you decode without buffering the whole stream Both of these seem to relate to bug #177670 which is a request to implement the "Dynamic MNG" feature, which is a private extension to the MNG spec. > * decoder will crash if it runs of memory in said buffering (along > with a number of other unchecked allocations) Is there a bug report on this? Re: comment #399 > i've read recent comments about using libmng to decode PNG images. I > didn't think that was an option given that it couldn't do progressive > rendering, hadn't gotten as much testing as libpng among other things. The current patch allows people to configure this way so we can get some testing. The normal configuration would be with the regular png decoder decoding PNG. I believe the mng decoder will decode PNGs correctly, but I doubt that it will be able to do it as fast because of extra stuff it must do. There's no need to speculate; people can configure both ways and run timings.
(In reply to comment #403) > Re: comment #402 > > * doesn't fire OnStop{Decode,Container,Frame} > > > > * you might want to see if necko now has the features that would let > > you decode without buffering the whole stream > > Both of these seem to relate to bug #177670 which is a request to implement > the "Dynamic MNG" feature, which is a private extension to the MNG spec. No - the first means that JNGs and MNGs won't work as background images. The second causes the MNG decoder to waste a lot of memory. > > * decoder will crash if it runs of memory in said buffering (along > > with a number of other unchecked allocations) > > Is there a bug report on this? No.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
+ Update to latest libmng CVS (removing another thing to lower code size) + Using Stop*, so mng also works on Backgrounds/CSS + remove the extra buffer + fixings from biesi's mail - some lines have out commented code ... should be removed later - starts displaying after all data is catched caused by the buffer changes ... maybe should changed again, if this patch work's correct. I hope I've all suggestions in this patch. If someone had more input, what needs to be done, he is greatly welcome. Glenn: What do we save if we remove the open_stream and close_stream callbacks?
Attachment #142993 - Attachment is obsolete: true
Patch id #143562 has a left-over instance of modules/libpr0n/build/_img_list so you will need to type "y" to allow patch to skip it. Otherwise it sucessfully updates mozilla, freshly downloaded from CVS.
>Glenn: What do we save if we remove the open_stream and close_stream callbacks? About 500 bytes. I'll check that change in to libmng CVS shortly.
Attached file Full MNG (1.0.6+) patch (trunk) bzip2 (obsolete) —
New Version: + update to latest libmng cvs. + start playing mng while loading + resolve problem when StartAnimation is called before loading is done TODO: Clean up some makefile.in's etc.
Attachment #143562 - Attachment is obsolete: true
Comment on attachment 144555 [details] Full MNG (1.0.6+) patch (trunk) bzip2 Patch #144555 works for me. r/sr?
Attachment #144555 - Flags: superreview?
Attachment #144555 - Flags: review?(tor)
Comment on attachment 144555 [details] Full MNG (1.0.6+) patch (trunk) bzip2 A couple things: * StopAnimation should probably cancel the timer before resetting the handle (btw, perhaps that should be using freeze/resume?). * Still a large number of unchecked allocations. * Comment in imgContainerMNG.h about buffering the whole stream can be removed and/or updated to reflect the current code. * Should not be registering image/x-mng. * Shouldn't be modifying the accept header (which shouldn't contain image/png either, but that's another bug). * Change to png mimetype in content sniffer shouldn't be necessary.
Attachment #144555 - Flags: superreview?
Attachment #144555 - Flags: superreview-
Attachment #144555 - Flags: review?(tor)
Attachment #144555 - Flags: review-
* Still a large number of unchecked allocations. Note that the MNG_ALLOC macro has an internal check. Only MNG_ALLOCX needs a subsequent check. I find two instances of MNG_ALLOCX in libmng that should be MNG_ALLOC, and we will fix those. They aren't active in moz anyhow because they are for decoding compressed text.
I was referring to allocations in the glue code, not in libmng.
Flags: blocking1.7?
Flags: blocking1.7? → blocking1.7-
Hello World, I know you all want MNG back into tree of mozilla. But please ... if you are not drivers, asa, tor or me ... DO NOT CHANGE flags of patches, blockings and else. This helps nobody ... aggresivity don't help us. While the last time I had problems with my debian installation and gcc 3.4 (it crashed randomly) I'm again back to gcc 3.3.3 ... but there was a code change in the networking part that stops us at the moment from havin a workin libmng inside mozilla. No, it isn't a bug in mozilla, it is a fact of design. The mozilla code was cleaned or corrected to work how the design it want, but that breaks us. The other tasks from tor are mostly resolved. Christian Biesinger have build a new linux mng.xpi and provide it on his page (it works with mozilla 1.6 but seems to be breaked in trunk builds). It have libmng 1.0.8a. This resolves crashers with libmng and the images that are generated from the new software of the blinkenlights project. Bad is, that 1.7 is declared as the new stable branch. Maybe Netscape 7.2 will depend on this and so will also miss the libmng plugin cause we won't have all working until 1.7 is ready.
So, assuming that 1.7 is released before libmng can be repaired to fit the new design, once libmng is repaired, would it be possible for someone to compile 1.7 with the fixed libmig and post Mingzilla 1.7 for Windows, Linux, and OSX somewhere so some of us can use and test it?
Attached file Full MNG (1.0.8a) patch (trunk) bzip2 (obsolete) —
New patch using libmng 1.0.8a and the new libmng pushdata functions, so the mng glue code now is compatible to the mozilla API. And that's all of changes in this release of the patch set. All other thinks of code cleaning and repair tor's buglist for mng are left out for the next days. Greetings Alex// PS: http://www.blinkenlights.de/torus-mng.en.html is a very nice sample animation. (With older libmng versions your browser will crash).
Attachment #144555 - Attachment is obsolete: true
Attached file Full MNG (1.0.8a) patch (trunk) bzip2 (obsolete) —
> * StopAnimation should probably cancel the timer before resetting > the handle (btw, perhaps that should be using freeze/resume?). done > * Still a large number of unchecked allocations. done > * Comment in imgContainerMNG.h about buffering the whole stream > can be removed and/or updated to reflect the current code. done > * Should not be registering image/x-mng. done > * Shouldn't be modifying the accept header (which shouldn't contain > image/png either, but that's another bug). left until image/png isn't there any more (And I think a bit other about accept headers, but that's an other problem) > * Change to png mimetype in content sniffer shouldn't be necessary. ??
Attachment #146226 - Attachment is obsolete: true
Alexander, if you think that this patch revision (1.0.8a) fixes tor's issues and should make it into the trunk, you will have to ask for r/sr again.
Just a question from someone watching this bug...why shouldn't mng be registered as image/x-mng?
Just a question from someone watching this bug...why shouldn't mng be registered as image/x-mng?
@Bernd I'm waiting for libmng 1.0.8, one thing from tor was left, I must speak with tor before and Glenn's report "it works" is outstanding. @Joseph MNG will be registered (in a unknown future *gg*) as video/mng and so it is at the moment registered as video/x-mng ... why it isn't registered as image/mng I don't know. So we have image/x-jng and video/x-mng yet. Greetings Alex//
re: accept-header issues, we removed jpeg and gif from the accept header since pretty much every browser out there accepts them. the current subject of debate is whether any content negotiation is being done with image types in the wild (not in theory). tor's thought (and it has validity) is that keeping image/png is equally bloating the accept header. Therefore adding image/x-mng etc is also useless from that perspective. But, that's a relatively minor side issue that we really need to hash out for png too, so it deserves a side bug.
(In reply to comment #410) > * Shouldn't be modifying the accept header (which shouldn't contain > image/png either, but that's another bug). Would you mind to explain why the Accept header should not be changed? How would Apache otherwise know that we can display PNG or MNG?
> tor's thought (and it has validity) is that keeping image/png > is equally bloating the accept header. Therefore adding image/x-mng etc is also > useless from that perspective. That logic doesn't work. "Everyone accepts GIF and JPEG, so putting them in the Accept: header is bloat. Only a few browsers accept MNG, so putting it in the Accept: header is bloat." Huh? :-) If MNG goes back in, it should be added back to the Accept header, until and unless every other browser has been supporting it for about five years (which is how long we've all had PNG support.) Gerv
Attached file Full MNG (1.0.8a) patch (trunk) bzip2 (obsolete) —
> * Change to png mimetype in content sniffer shouldn't be necessary. done Also removed a crasher in StopAnimation (excuse there was a ! to much). Now the patch should be up to date and only libmng 1.0.8 seems to be outstanding.
Attachment #146839 - Attachment is obsolete: true
Re: patch id#1470948 -- it works for me (FreeBSD 5.0, gcc 3.2.1). Patching from this afternoon's CVS 1.8a distribution is flawless, but when patching the 1.7rc1 distribution, the patch fails to update modules/libpref/src/init/all.js (but this can probably be ignored, or you can just update manually from all.js.rej which is an easy one-liner). Either way it display's MNG, JNG, and PNG satisfactorily. tor: this patch seems to address all of the concerns you have expressed. Do you have more?
Some source things: * MOZMNG in configure.in should be bumped * remove dependentLibs.h * remove whitespace change in png content sniffer * image/x-jng is being sniffed/registered even if libmng is built without JNG support (the default configuration in this patch) How big is the resulting libimgmng.so these days?
Isn't there also still an issue with which code to use for PNG files? If this patch makes us use libmng to decode PNG files isn't there a big risk of regiressions for PNG rendering seing how much time and testing has gone into the current libpng code. Of course this is a moot point if this patch lets us still use the current libpng for PNG files. Is there any way that libmng could use the current libpng? If not, could libpng be modified so that would be possible?
As I read it, the patch will only use libmng to decode PNGs if the png decoder is disabled at configure time. We definitely want to keep using libpng for PNG files.
@sicking The png files will only decoded by libmng if you define this in your configuration, else png decoding is done by the libpng. I think there will be less regression with change of decoding png from libpng to libmng ... it's the same circle of programmer(s) who do the libs. @tor Ok, will do the missing things (some of them are already fixed in my tree today) I compile with MNG_BUILD_MOZ_MNG and have libimgmng.so 186512 libimglib2.so 178856
tor asked: How big is the resulting libimgmng.so these days? On the FreeBSD5.0/gcc3.2.1 platform, MNG_BUILD_WEB_NO_JNG configuration, ac_add_options --enable-image-decoders=mng,gif,jpeg,bmp,xbm (i.e., libmng providing standalone PNG support, reduced MNG support -- no Delta_PNG) size libimgmng.so is 109930 bytes and size libimglib2.so is 154234 bytes. MNG_BUILD_MOZ_NO_JNG configuration, same decoder set, libmng providing standalone PNG support and full MNG support, no JNG support size libimgmng.so is 129815 bytes and size libimglib2.so is 154234 bytes. MNG_BUILD_MOZ_MNG configuration, with png in the decoder set, (libpng providing standalone PNG support) size libimgmng.so is 200664 bytes and size libimglib2 is 201063 bytes. Other configurations are supported but are less interesting.
Isn't the most interesting configuration what could go into a default build? I.e. having libpng enabled and having as small libmng as possible (while still keeping it usefull).
Does opi's patch work well for everybody? I did some tests on OS/2 and found that is causes Mozilla from the 1.7 branch to crash when trying to display two specific MNG/JNG files: I built Mozilla with ac_add_options --enable-crypto ac_add_options --disable-debug ac_add_options --with-extensions=default,irc,inspector ac_add_options --disable-mailnews and with and without ac_add_options --enable-optimize=-O2 started it and drag-drop-loaded a few image files, including my three MNG/JNG testcases: Animation1.mng (MNG animation testcase, the 4th attachment of this bug) pnglogo-grr-anim-lc.mng (from libmng webpage) sasaki.jng (little girl with cat on her head, probably from libmng page) The effects are these: - "normal" graphic files like PNG, BMP, JPEG are all loaded normally - Without activating MNG/JNG (only the above options) many browser windows are opened when loading one of the above testcases - when adding ac_add_options --enable-image-decoders=default,mng nothing is displayed for sasaki.jng (as expected) but pnglogo-grr-anim-lc.mng crashes the browser every time, while Animation1.mpg crashes the browser when compiled with -O2, and is displayed but not animated without optimization - when using both ac_add_options --enable-image-decoders=default,mng ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG sasaki.jng also crashes the browser every time - With a patch I used to build my Mozilla 1.6 (made from attachment 134552 [details] [diff] [review] dated 2003-10-30 and the libmng 1.0.6 sources) and the MNG_BUILD_FULL_MNG setting everything displays OK, no crashes occur, and Animation1.mng is indeed animated So, is this an OS/2-only problem or does someone observe this on other platforms, too?
tor says: * MOZMNG in configure.in should be bumped Yes, to MOZMNG="((1<<16)|(0<<8)|(8))" MOZPNG should also be bumped, to 10205. You want to do that change separately?
Peter W says: These crash on OS/2: Animation1.mng (MNG animation testcase, the 4th attachment of this bug) pnglogo-grr-anim-lc.mng (from libmng webpage) sasaki.jng (little girl with cat on her head, probably from libmng page) The first two look fine on my FreeBSD5.0/gcc3.2.1 platform. pnglogo-grr-anim-lc.mng can be found at www.libmng.com/pub/mng/mngpics.html at the top of the page. I think sasaki.jng was someone's avatar on mozillazine forums, now long gone.
Sorry for the spam, but does anyone have any build available for WinXp/Linux (Fedora) with different build options some of us could test out to make sure everything is working correctly and help find bugs? Both Suite and Firefox builds would be nice, I'm willing to do as much testing as needed. Again, sorry for the extra spam if this is not an appropriate request. -Jed
sakaki.jng was my avatar, it was removed from my profile because it crashed Mozilla. Perhaps this bug is relevant: http://bugzilla.mozilla.org/show_bug.cgi?id=196670 It's a legit JNG, no special code as far as I know.
sakaki.jng contains an extraneous CRLF after the IEND chunk. It may display in some JNG decoders but not in others. The data-streaming inside libmng and the gluecode has changed, and it's probably complaining now about the extra bytes.
@Gerard Can you fix that problem for libmng 1.0.8? Cause no input, correct or not, shouldn't crash. Also http://www.libmng.com/MNGsuite/images/MNGPAST16a.mng is outstanding, it is pushed in one with 711 byte (or what I'd wrote in my mail). @Jed I hope I get Windows Builds in the near future, all builds can be found on http://sourceforge.net/project/showfiles.php?group_id=92539 (Oh, it seems there is a Windows Firefox/MngFox build present)
Actually, I found the first part of the problems I reported in comment 432, on a build I just made from the 1.7 branch on Linux. Drag-drop-opening of any MNG/JNG file from nautilus onto the browser window results in many windows opening without MNG/JNG activated. Only help seems to be Ctrl-Q... I guess this is a problem of the glue code. @Ashi (comment 436): I doubt that the same compiler problem of MS VC (from of bug 196670) is also present in gcc-3.2.2 on OS/2 with and without optimization. But until now I did not manage to get a debugger working on OS/2 and have too little knowledge of compilers, so I cannot be sure. Actually, sasaki.jng is attachment 130784 [details] of this bug. Is it possible to move the discussion on the details of opi's patches into a new bug or into some newsgroup (don't know which one)? This bug gets so awfully long, CCs too many people, and I find it really hard to handle at home over analog modem.
opi says: (Oh, it seems there is a Windows Firefox/MngFox build present) That was built with Jason Summers' libmng-1.0.6 plugin, not your latest patch.
Additional tests under Linux, now built with ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG ac_add_options --enable-image-decoders=default,mng As under OS/2 Animation1.mng is displayed (the AOL text) but not animated, when loaded locally (URL file:/<path>/Animation1.mng). When loaded from the URL of attachment 124879 [details], the animation is shown. pnglogo-grr-anim-lc.mng or the other hand shows the animation, when loaded from a file: URL and from a server. The crashed I noticed before are therefore OS/2 specific. I hope to be able to figure out soon how to properly debug this. Additionally, I found that loading MNGs from an FTP server does not work. Mozilla asks for a viewer or to save the file. For PNGs on the same server it works. I tested this at <ftp://swrinde.nde.swri.edu/pub/mng/images/> and <ftp://swrinde.nde.swri.edu/pub/png/images/png/>.
FTP URLs not working is probably because the tables in uriloader/exthandler/nsExternalHelperAppService.cpp haven't been modified.
(In reply to comment #442) > FTP URLs not working is probably because the tables in > uriloader/exthandler/nsExternalHelperAppService.cpp haven't > been modified. instead of doing that, a category entry for "ext-to-type-mapping", name "mng", value "video/x-mng" (or what the type is), should be added.
Some others and I can't get this patch to apply. I tried doing: patch < /patch/mozilla-mng-patch-040427.diff patch -p 22 < /patch/mozilla-mng-patch-040427.diff Then I tried: sed 's/\/mnt\/mozilla_compile/\./g' /patch/mozilla-mng-patch-040427.diff > diff.txt patch < diff.txt I tried it in both the ./mozilla directory and the ./mozilla/.. directory. From the ./mozilla directory, some chunks applied, but not all. We don't have /mnt/compile_mozilla and even when I tried a symlink to my real mozilla directory it didn't work. In all cases, it asks for a filename to use for some|all of the files. http://forums.mozillazine.org/viewtopic.php?p=503059#503059
For information how to use the patch please take a look at http://www.opiswelt.de/mozilla/mng.html
(In reply to comment #444) > patch < /patch/mozilla-mng-patch-040427.diff > patch -p 22 < /patch/mozilla-mng-patch-040427.diff please read "man patch". you want -p1, and apply it inside the mozilla/ directory. or use -p0 and apply it above the mozilla directory.
sorry, that should be -p2 instead of -p1.
Attached file MNG (1.0.8a) patch (trunk) bzip2 (obsolete) —
@tor * MOZMNG in configure.in should be bumped done * remove dependentLibs.h done * remove whitespace change in png content sniffer done * image/x-jng is being sniffed/registered even if libmng is built without JNG support (the default configuration in this patch) done @Peter Weilbacher * loading MNGs from an FTP server does not work done as biesi it wants * OS/2 crashers can't help without stack traces Please try also to add the option ac_add_options --without-system-mng Another problems: If you use the xpi and go to sites that have mng's in an <img> Tag, but the imges are send back from server with mime-type text/plain won't displayed. This is a buggi workaround for stupid admins, won't fixed here, cause it isn't a mng problem. Hint: Tell the webadmin, he should add the correct mime-types to his server. If you wan't open directly a mng and the server send's mime-type text/plain then mozilla opens a "what to do" Dialog but tells the user the correct mime type "video/x-mng". Buggie workaround for stupid admins. Fix is in way. Hint: See above. Why the MNGZilla builds show application/octet-stream on this issue and not "video/x-mng" will be ironed with out at the moment with bz.
Attachment #147094 - Attachment is obsolete: true
Patch #1475778 works for me (FreeBSD 5.0/gcc 3.2.1), when applied to the mozilla-1.7rc1 distribution. As before I had to patch one line of all.js manually.
(In reply to comment #448) > * OS/2 crashers > can't help without stack traces I can't produce a gdb-like backtrace, but it is crashing in libmng code not the glue code. When I try to load sasaki.jng or pnglogo-grr-anim-lc.mng it crashes at line 690 in libmng_display.c because pData->fDisplayrow is undefined (NULL). Didn't yet find out why that is and why it works on Linux. When displaying Animation1.mng the pointer is correctly initialized and that line calls mng_display_rgb8_a8(pData) at libmng_pixels.c:1378. > Please try also to add the option > ac_add_options --without-system-mng It is using the libmng code contained in your patch as I confirmed in the debugging session.
Peter, The special case for OS2 and other platforms is inconsistent with the glue code which uses the same canvas types for all platforms. In modules/libimg/mng/mozlibmngconf.h, change the following: #if defined(XP_WIN) || defined(XP_OS2) || defined(XP_BEOS) || defined(MOZ_WIDGET _PHOTON) #define MNG_SKIPCANVAS_RGB8 #define MNG_SKIPCANVAS_RGBX8 #else #define MNG_SKIPCANVAS_BGR8 #define MNG_SKIPCANVAS_BGRX8 #endif to simply: #define MNG_SKIPCANVAS_BGR8 #define MNG_SKIPCANVAS_BGRX8 which happens to be what you get on Linux.
Attached file MNG (1.0.8b) patch (trunk) bzip2 (obsolete) —
* OS/2 crashers (also win, if it crashed there) done (updating to latest libmng cvs, where this was corrected) * As under OS/2 Animation1.mng is displayed (the AOL text) but not animated, when loaded locally wontfix It seems that local files are loaded syncron (remote files asyncron). The image self isn't animated but its state depends on how much is loaded. Cause of syncron load, the image is ready when it will displayed first. If you try another animated mng, then you see, that it also animate after loading. * Why the MNGZilla builds show application/octet-stream on this issue and not "video/x-mng" will be ironed out. should be fixed on trunk * If patch is applied but mng not compiled in, open a mng file directly causes many windows opened. Will look into this next time. Does this also happens with BMP's? I hope, I've all. New builds and xpi's on http://www.sourceforge.net/projects/mngzilla will come next week for Linux AND Windows(compiled with gcc so maybe slower then msvc builds).
Attachment #147577 - Attachment is obsolete: true
Confirmed that 'pnglogo-grr-anim-lc.mng' now doesn't crash it. (I've been secretly building with MNG in, and noticed that.) Some JNG files still don't work, but it's never worked. It's quite possible I'm missing something, or that support for pure JNGs hasn't been added yet. At least, from my test page for image working-ness and for crashing. A bunch of images taken from either my hard drive, or from the MNG/JNG testcase sites: http://mtigas.blogdns.net/files/workstation/imgsuite/index.html Have compiled Firefox (Aviary stable branch) with MNG (based on 2004-05-07 05:52 PDT patch) and SVG, and planning to compile Trunk sometime in near future. Will probably optimize different versions, but currently I have publically posted a generic Windows G6 build. Has some other customizations in it, but generally stable. (Aviary is doing nicely.) Using: ac_add_options --enable-image-decoders=default,mng ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG Link: http://forums.mozillazine.org/viewtopic.php?t=78653 Experiencing no crashes, and everything looks stable on the Windows end. Sorry for bugspam, just announcing as to let more widespread testing on the (updated) MNG code take place.
@Alexander Opitz: I have been doing MNG builds for myself: One is http://pryan.org/mozilla/firefox/amano/Fx-2004-06-08-O1-Gopher-MNG-Exp.exe that includes Jason Summer's mng plugin (as GlennRP reported, it is at 1.08a libmng state) And the second one is http://pryan.org/mozilla/firefox/amano/Fx-2004-05-12-O1-Gopher-MNG-Exp.exe with mng support manually patched in (using your latest diff file). When I surf to http://www.libmng.com/MNGsuite/dynamic_embed.html to test the dynamic mng, the Jason Summer plugins works, but my modified build (the diff file one) fails: Australia and the buttons are visible, but all mouseover effects don't work. How is that possible as both "implementations" are at libmng 1.08 state?
Bernd: Opi's patch, by default, is configured to build the MNG_BUILD_WEB_NO_JNG variant, which does not include support for dynamic MNG. To get dynamic MNG support you will need to add "#define MNG_SUPPORT_DYNAMICMNG" to modules/libimg/mng/mozlibmngconf.h
Re comment #445: Also you need to remove the line #define MNG_SKIPCHUNK_evNT from mozlibmngconf.h. I don't know if it will work or not; it may be that some dynamic-MNG enabling has to be done in the glue code as well.
I am running a --enable-image-decoders=mng,gif,jpeg,bmp,xbm --enable-mng-type=MNG_BUILD_FULL_MNG build since end of April under both OS/2 and Linux. Only today did I encounter PNGs in a "normal" webpage that do not display correctly with the MNG decoder but do with the PNG decoder in the official Mozilla.org/IBM builds. I guess that these problems are already known to the libmng developers but now that I am adding to this bug I can list them anyway in case they are just not contained in MNG_BUILD_FULL_MNG: 1. The first problems I found were at http://www.bo.astro.it/report02/node44.html. In the MNG build the formulae appear white on black and the plot does not have any content besides black background. In the standard PNG build everything appears correctly (black, background transparent). 2. So I went to check, and the "Illegal and/or corrupted PNG images" from http://www.libpng.org/pub/png/pngsuite.html not only do not display but lead to a few hundred screenfuls of empty space. In the standard PNG build they just appear as normal cannot-display-icon. 3. There also is a webpage that describes all the errors browsers can make when displaying (alpha) transparency of PNGs (but I lost the URL and spent 30 minutes looking for it without success). The standard PNG build gets them all displayed (nearly?) perfectly, while the build with MNG instead of PNG makes several errors. I just realized that I still have to answer opi's question from comment 452: > * If patch is applied but mng not compiled in, open a mng file > directly causes many windows opened. > Does this also happens with BMP's? I haven't tried yet to compile the browser without BMP support, but with the above .mozconfig arguments it does not. I will try to build without BMP and test in the coming days. Finally, I have made OS/2 builds with MNG and a new MNG XPI for OS/2 available on http://weilbacher.org/Peter/mozilla.html, in case an OS/2 user reads this bug but not the npm.os2 newsgroup. I guess it's time that I start using some JNG or MNG on that page...
I just compiled Mozilla (1.7 branch) on Linux with ac_add_options --enable-image-decoders=mng,gif,jpeg,xbm ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG (so without BMP support) and now I see the same problem with BMPs, too: try to open a BMP and lots of new Mozilla browser windows open, the only way around it to use Ctrl-Q.
Its a shame the only choice we have for animations are gifs... what the hell are you guys doing ? that would have been my priority if i had sufficient knowledge in programming..
Brice: Please read bug comments before making one yourself. As you can see by the attachments at the top of the bug, this is being worked on. Therefore, your comments are of no value. Please save such comments for http://forums.mozillazine.org/ and don't litter bugs with them. This goes for everyone else, too.
(In reply to comment #459) > Its a shame ... A comment such as "This bug should really be a blocker for Firefox 1.0" (if I caught your drift) is more likely to be accepted than your comment. This example comment is also likely more veridical than your comment.
(In reply to comment #461) > A comment such as "This bug should really be a blocker for Firefox 1.0" (if I > caught your drift) is more likely to be accepted than your comment. This > example comment is also likely more veridical than your comment. Good idea :) Requesting blocking-aviary1.0
Flags: blocking-aviary1.0?
I second the blocking 1.0 There is already a mature patch in the works .gif is patented by unisys, and .mng would be a good replacement for .gif (and its even better than .gif). Also, this being released in a 1.0 version would make people notice it more and put the pressure on other browser makers.
The GIF patents expired last year in the USA. The patents in Japan and Europe have expired in the past couple of weeks, and I believe the patent in Canada has about 10 days left. So patents aren't much of an issue any more...
(In reply to comment #464) > [...] patents aren't much of an issue any more... but, (for webdesigners, anyway) alpha transparency *is*
The code is to much experimentel to add it to the aviary branch. There will be xpi's to install mng support. We also will try to make MngFox/MngZilla on the known sourceforge page. Please respect the first lines out of comment #413 and don't change blockers and such thinks.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
(In reply to comment #464) > The GIF patents expired last year in the USA. The patents in Japan and Europe > have expired in the past couple of weeks, and I believe the patent in Canada has > about 10 days left. So patents aren't much of an issue any more... Unisys' patent has expired, but IBM's patent is still valid. So patents are still an issue (even if the technical advantages of MNG are enought to choice them instead of GIF)
(In reply to comment #467) > Unisys' patent has expired, but IBM's patent is still valid. The article "Why There Are No GIF files on GNU Web Pages" supports your claim: http://www.gnu.org/philosophy/gif.html "... the latest expiration date seems to be Friday 11 August 2006"
I hate to contribute to the bugspam, but I think it's worth noting that IBM has never tried to enforce its patent, probably because it would likely be found to be invalid, since it covers exactly the same "invention" as the Unisys patent. See, for instance, http://www.kyz.uklinux.net/giflzw.
As a basic user, i can't understand why you wonder about GIF patents. MNG is simply better... So just implements it ! , or remove the PNG support too, arguing that GIF can replace it and IE doesn't support PNG well !
Found the webpage again that I was referring to in comment #457: http://entropymine.com/jason/testbed/pngtrans/ When the MNG decoder is used for PNGs, Mozilla displays the "RGB binary transparency" and "Grayscale binary transparency" examples with a black background.
Removing .png support, ignoring technical reasons, would be unfair to those who have put work into making quality .png support in the browser. I also don't see what we'd gain by dropping .png and we'd lose a lot since some skins and websites use .png. Also, the .png code is not really that much of the code of Mozilla since the image library abstracts a lot of the functionality shared between all image decoders. Also, from what I've heard, there are CSS tricks to get alpha transparency to work properly for IE in .png images if people have DirectX installed, which is nearly everyone. These kind of CSS hacks are becoming more popular to fix IE bugs on Websites, can be commented out using conditional comments, and are often even given away as scripts for your website (such as IE7 on sourceforge -- which doesn't yet afaik handle the .png transparency issue).
(In reply to comments #470 and #472) I realise the suggestion to remove PNG support is somewhat tongue-in-cheek, but the reasons not to do so make me cringe. Not many sites support style sheets or JavaScript properly either, and IE does it differently, so why not also suggest that these either conform or be removed altogether? The answer, like the rest of the Mozilla code base, has a lot to do with doing the right thing and getting it right. A lot of work has gone towards making Mozilla support these these advances in technology, and at the same time, because of the ubiquitous and transparent nature of the browser, Mozilla is something of a flagship for them. The mozilla.org code base has had exceptional support for CSS, DOM, JavaScript, XML and (yes!) PNG from the very beginning, and these specifications are only now coming into prominence in the mainstream, because developers are starting to understand that there's a right way and a wrong way to do things. Had browsers other than Internet Explorer not bothered to support these things back then - some six years ago - their importance would have been lost forever, drowned in a sea of Web pages using IE's busted implementations. Melodrama aside, that is why I voted for this bug, why I'm not surprised this bug has 701 other votes, why I agree that MNG/JNG support must absolutely be installed by default, and why I agree that it should block the aviary. (I'll save the similar argument for Scalable Vector Graphics - SVG themes, anyone? - for a more relevant time and place.)
reasons why this isn't going to block aviary 1.0 (again, posting to prevent more advocacy posting. If you want to debate this with me, feel free to email) a) the code isn't ready, per the owner of the bug and the person responsible for getting things to a point where it can be added back into CVS. We're on way too short of a timeline to take major last minute code. b) no one working on Firefox/Thunderbird really wants this at this point (speaking as one of the people heavily involved in Firefox). Thunderbird stopped building with MNG before CVS removal took place. Firebird was probably going to do the same, but CVS removal came first. Its not something that'll likely change going forward, unless MNG support is really low cost (i.e. not 200-300k). At 50-80k the case becomes stronger, of course. The "if you support it, they will come" argument is weak, since we did support this for three years and the content didn't come. c) Content that 90% of the web doesn't support isn't going to get created in any substantive way. MNG has the advantage of being more ideologically pure than Flash etc, but if people aren't using it, its cruft, and that's the reality. Given the choice, we'd be much better off bundling Flash with Firefox based on the "size vs. usability boost" equation. I realize lots of people don't like Flash for a myriad of reasons, but users don't care.
the point is : we need Mozilla to implement and promote MNG to be able to use it "noone" used it because IE didn"t implement it. it's simply that. nothing else but it's also the case with alpha-transparency png and thanks to mozilla and others we are able to use it for mng, we need the same thing, and mozilla CAN support it and KEEP it it's not 3 years we need, it's 5 or 10 . it will become useful ONLY when mozilla (or others browser with mng support) will be strong enough to interest developpers. in the meantime, mozilla as to do the same thing it do with png or xbl or others stuff : support it . to prepare the future (in _years_ , many years) animated gif is not enough flash is not enough we need animated format with alpha and 24b support (and no, flash is not enough, flash is an other problem ,and it's good mozilla has plugin for it but it's proprietary and never mozilla will be allowed to incorporate native flash support) mozilla foundation should be more thorough and truly support SVG and MNG. we don't need simply a good webbrowser , we need a better WEB and mozilla is the only browser project which can listen web designer and developpers.
the point is : we need Mozilla to implement and promote MNG to be able to use it "noone" used it because IE didn"t implement it. it's simply that. nothing else but it's also the case with alpha-transparency png and thanks to mozilla and others we are able to use it for mng, we need the same thing, and mozilla CAN support it and KEEP it it's not 3 years we need, it's 5 or 10 . it will become useful ONLY when mozilla (or others browser with mng support) will be strong enough to interest developpers. in the meantime, mozilla as to do the same thing it do with png or xbl or others stuff : support it . to prepare the future (in _years_ , many years) animated gif is not enough flash is not enough we need animated format with alpha and 24b support (and no, flash is not enough, flash is an other problem ,and it's good mozilla has plugin for it but it's proprietary and never mozilla will be allowed to incorporate native flash support) mozilla foundation should be more thorough and truly support SVG and MNG. we don't need simply a good webbrowser , we need a better WEB and mozilla is the only browser project which can listen web designer and developpers.
Please stop arguing for or against the inclusion, it doesn't help either way. And DO NOT request any blocking flags or considering that, as you only upset people. opi and Glenn are working on getting libmng and the glue code working well enough to go into CVS trunk again, but disabled by default for now. Any other steps, as inclusion of any profile into any builds is up to discussion on a second step, I'd say. We should just get something working back into CVS again for now, and consider this first step fixed. There's a "yes" from driver to support of a certain extent in default builds, but I'd believe that a second step. Please STOP SPAMMING THIS BUG REPORT with anything that does not help in the process of achieving that first step.
I'd just like to point out the ridiculousness of Mr. Conner's comment about bundling Flash being more important that MNG support. The difference between Flash and MNG in this context is that you can easily install the Flash plug-in; I've done it (in other users' profiles, of course). But it doesn't surprise me that the Firefox developers don't want it. They'd probably yank out XML, CSS and JS support if not for those languages being used by the theming system. Of course the obvious solution is to re-add the code and just not compile the birds with it. Since Seamonkey users prefer features over smallness, this would seem to please both camps.
Is this a bug report or a Slashdot story? Many of the comments I'm seeing here belong on the later rather than the former. The fact is MNG support was pulled because because of the cost/benifit ratio, not some dark plot in favor of animated Gifs. Sugestions on reducing the footprint of MNG support are the way to get it back into the products, not wild accusations and demands that something of intrest to a tiny minority be included regardless of it's effects on footprint. (Sorry for adding to the Spamload)
(In reply to comment #474) > b) no one working on Firefox/Thunderbird really wants this at this point > (speaking as one of the people heavily involved in Firefox). Thunderbird > stopped building with MNG before CVS removal took place. Firebird was probably > going to do the same, but CVS removal came first. Its not something that'll > likely change going forward, unless MNG support is really low cost (i.e. not > 200-300k). At 50-80k the case becomes stronger, of course. The "if you support > it, they will come" argument is weak, since we did support this for three years > and the content didn't come. I think (or at least hope) that Firefox 1.0 will make a _really_ big splash. Heck, 0.9 was pretty big. There's a unique opportunity here to simultaneously have a bunch of excellent demos and a much-desired new feature, _and_ throw a whole bunch of MNG capable browsers out there, at a time when the community is going to be excited about firefox and keen to play with the features. I think that not only will they come, but it may drive adoption of firefox, which will drive adoption of mng... It sounds like we are talking on the order of 100k, which is presumably before compression. I believe there's a strong case to include it and testing the hell out of it before release. > Given the choice, we'd be much better off bundling Flash with Firefox based on > the "size vs. usability boost" equation. I realize lots of people don't like > Flash for a myriad of reasons, but users don't care. Good flash support is definitely useful, but flash cannot do many of the things MNG can do, due to its nature as a plugin. MNG support is also much more compact, and has potential to have a larger benefit (from bundling), IMO. And yes, I know this is very late in the piece ;-)
RE: comment 479: "something of intrest to a tiny minority" 702 people voted for this bug. Not a demand or accusation. It seems that this argument, that there is little interest in mng, has been proven incorrect. If there is still other valid reasons for leaving it out, then let's discuss those reasons. I understand that a comprimise has been reached, to say that if the code size can be reduced to a certain point, then it can be included again, just to clarify, what is that code size? Is 100k not small enough?
I Knew that vote number would come up. After a campaign to vote for this bug you got 702 people out of about 6 Billion people on the planet, Tens of millions of Internet users, and tens of thousands of web developers. That IS a tiny minority of any of those groups. The Fact is most users don't care because almost no sites have MNGs, and most site designers don't care because over 90% of the people visiting their sites wouldn't be able to see the MNGs and that wouldn't change if all Mozilla products had them starting tomorrow. I'm part of the tiny minority that would like to see MNG supported, but not at any cost. I don't have any say on the footprint threshold for MNG inclusion, but common sense should tell you the smaller it is the greater the liklyhood it will be picked up.
Keith, John, Sam, Kevin and others, could you please just SHUT UP and stop spamming us with things that belong into a discussion board but not a bug report? The more useless comments are made, the less attention will this issue get. If you want to change something, then help opi and Glenn, if you can't contribute other than throwing arguments about what to do at the others, then kindly refrain from commenting (and even from anwering me in this bug report). Thanks.
okay, i am the rude one who voted for this bug; let me be the one to wrap up the spam. i dont care how it happened; but a whole bunch of us started to contribute to making free software. i saw projects where the priorities were 1)freesoftware and 2)good software. one day you wake up and see you volunteer for 1) propietary software and 2)not good software. you get angry and frustrated. flash is propietary and not good software. it is popular. i did not volunteer for popularity and probably many of the people actually writing the code used to get beat up as kids for not being popular. mozilla is the high school of software i think. popular **** not good hearted volunteers. whatever reasons "flash" is there and mng is not all go back to this same pubescent issue. please, for heavens sake? what are you doing and why? is there a browser fork of this peoples browser that is interested in free software first and good software second and popularity not at all?
one more thing. spam. spam is "Unsolicited e-mail, often of a commercial nature, sent indiscriminately to multiple mailing lists, individuals, or newsgroups; junk e-mail." (http://dictionary.reference.com/search?q=spam&r=67) this email is something you sign up for. the stuff being called spam are actually questions that are *not* of a commercial nature. the answers seem to be commercially motivated. if you use the actual definition of spam, the answers for why this flash condition exists are spam and the questioning of the policy is not. i did not consider the recent flurry of "what the hell?" questions to be spam, less spam in the answer and more actual words of fact would be nice.
(In reply to comment #485) >one more thing. spam. spam is "[...]; junk e-mail." >(http://dictionary.reference.com/search?q=spam&r=67) Junk e-mail. Junk. Worthless. In the way. Annoying. Exactly what the most of the comments on this bug is. Besides, any dictionary will always be lacking and outdated, as every word has different semantics for every person, as well as continually having its semantics updated. I could refer you to the case of the Danish word, a "bjørnetjeneste", but I doubt that would mean much to you. Please, I want MNG and JNG in Gecko too, but I don't spam this report with reasons why. And I'm tired of reading people arguing *for* inclusion of this. (No one is against this, from what I can see. There's just a price to pay for it. As is with everything.) I don't know how to program in C/C++/pretty much anything but Python, PHP, and a wee bit Perl, but I know that some of you are able to, so go and mess with the MNG code and try to improve and reduce it instead of adding more useless (junk!) comments to this bug. Go to the MozillaZine, lovely place that is, and discuss about including this all you want, and then leave this bug's comments for people who are *ACTIVELY & ACTUALLY WORKING ON IT*! That way, those who want to discuss can do that, and those who want to hack/program/work/test/debug can do that. No one will get annoyed would be annoyed with that. - Freso, with his first Mozilla Bugzilla comment ever. Too sad it had to go out to something like this.
Re: comment #471 A fix for the problem with binary transparency handling in standalone PNG files has been checked in to libmng-devel CVS. The 16-bit images are still shown incorrectly under the MNG_BUILD_WEB_NO_JNG and MNG_BUILD_MOZ_MNG configurations but that cannot be helped, due to the 16-bit transparency information being deliberately thrown away. MNG_BUILD_RAW_MNG and MNG_BUILD_FULL_MNG show them all correctly.
Attached file MNG (1.0.8b1+1) patch (trunk) bzip2 (obsolete) —
* updating to latest libmng cvs (08.07.04) * PNG transparency problem resolved, but on 16bit PNG's and no 16Bit support compile the Transparency bit may be cutted. * If patch is applied but mng not compiled in, open a mng file directly causes many windows opened. Bug is somewhere inside mozilla. Is something left out?
Attachment #147886 - Attachment is obsolete: true
> * If patch is applied but mng not compiled in, open a mng file directly causes > many windows opened. > > Bug is somewhere inside mozilla. hmm, if you're changing the accept-header so that Moz thinks we do handle it, there might be a nasty loop somewhere in there. This is the whole network.http.accept.default pref issue that tor mentioned. We shouldn't modify that unless MNG is indeed being built. (You can use the preprocessor in all.js now)
Apply this patch after applying patch #152566. Apply it from the mozilla/modules/libpr0n/src directory. This should cause imgLoader to set the MIME type only for those formats that are actually being built. I can't reproduced the many-windows-opening problem so I don't know if it fixes that. Someone who is experiencing the problem, please test.
Where can we get recent nightlies with the new MNG code compiled in so we can help test it for issues ? Stable issuefree MNG is a requirement for bug 48893 and implementing bug 48893 goes towards fixing this bug as it reduces the oversize of Mozilla. BTW I don't see any bug about using the JNG decoder for decoding JPG .. Is there some reason for this ? (Perhaps the JNG decoder uses functions from the JPG decoder instead ?)
Where can we get recent nightlies with the new MNG code compiled in so we can help test it for issues ? Check the mozillazine forum on 3rd party unofficial builds. There are several people regularly building MNG (and SVG) enabled Firefox and Mozilla. There are binaries at mngzilla.sf.net, but not the most recent ones. Stable issuefree MNG is a requirement for bug 48893 and implementing bug 48893 goes towards fixing this bug as it reduces the oversize of Mozilla. The recent patches here can be used to implement/test bug #48893. You simply delete "png" from the IMAGE_DECODERS list: ac_add_options --enable-image-decoders=mng,gif,jpeg,bmp,xbm If you are feeling particularly rambunctious, you can also delete gif and bmp. BTW I don't see any bug about using the JNG decoder for decoding JPG .. Is there some reason for this ? (Perhaps the JNG decoder uses functions from the JPG decoder instead ?) Right. As mentioned in a couple of comments in bug #48893, libmng uses libjpeg to decode JNGs so there's no potential savings there.
Attached patch Patch MIME sniffer code (2) (obsolete) — — Splinter Review
Unwrapped some long lines in the patch that were wrapped.
Attachment #152660 - Attachment is obsolete: true
@Glenn The patch seems to be ok, can you please make it working without applaying mng patch, open a new bug, block this bug and add attach the patch on the new bug. The patch should be done with "diff -u8p -r" and best from ./mozilla ... I think we can land this patch fast, then I update the mng patch to also had this included.
Status: NEW → ASSIGNED
In fact I'm planning exactly that but have PM'ed Peter to test first because my platform doesn't exhibit the many-open-windows behavior. I agree that the bug is probably really unrelated to MNG.
Depends on: 250936
Opi: re comment #494, done. See bug #250936.
How can my business support MNG if the best browser does not want to include it on its releases due to size. My business is all about open source for small/medium size businesses. If the open source like mozilla does not include MNG outright then It will be hard to sell it to the businesses.
There's a free, more efficient way than animated gif to display small animated pics, and with my last mozilla update, mng is no more supported ? Why ?
Because its still being worked on. Give them time to do it right.
Is size really the hold up for getting mng support? If so that's just dumb. Who cares about 200-300k extra.
Hereby I propose changing this bug's summary to "DON'T SPAM THIS BUG!!!1 (its purpose is to restore MNG and JNG support)"
I compared the filesize of two unofficial builds. A 0.9.2 release build from stipe without MNG and packed with 7z. And a 0.9.2 release build from amano with MNG and Gopher (and some other small things) .. also packed with 7z. The amano build was 58 kilobytes larger. To make an acurate apples to apples comparison though , we need to compare two almost identical builds where the only diffence is the MNG support. No such two builds exist yet but perhaps someone will build them.
Whiteboard: PLEASE USE BUG #204520 TO COMMENT ON TECHNICAL ISSUES. → READ EVERYTHING BEFORE COMMENTING. PLEASE USE BUG #204520 TO COMMENT ON TECHNICAL ISSUES.
Had trouble building this on the AVIARY branch recently. imgContainerMNG.cpp m:\Build\AVIARY-SAMUKE-SSE2\build\dist\include\gfx\nsColor.h(44) : fatal error C 1083: Cannot open include file: 'nsStringFwd.h': No such file or directory make[5]: *** [imgContainerMNG.obj] Error 2 Closer inspection led me to the checkin for bug 242254, fixed on the branch, particularly to the modifications to nsColor.h. Not quite sure how to look at this (I don't code besides HTML), however normal (without MNG patch) building is a-okay. Attachment in question is attachment 153213 [details] [diff] [review]. Particular file in question: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/gfx/public/nsColor.h&rev=AVIARY_1_0_20040515_BRANCH&root=/cvsroot
Hi, the problem is known there will be an updated patch but at the moment I can't make win builds with mingw (caused by an other bug of mozilla). But at the end of next week I'll provide a new patch (including libmng 1.0.8 final) against trunk, maybe I make one against AVIARY BRANCH
Severity: major → enhancement
Flags: blocking1.5b-
Flags: blocking1.4.1-
Flags: blocking1.4-
Keywords: helpwanted, regression
I don't get this really. Will mozilla / firefox have MNG support or not ?
:: Shakes magic 8 ball :: The result comes up: Undoubtedly. Stefan: As you can see, there has been a lot of activity in this bug, meaning things are still in the works.
Changing this to "enhancement" and removing the "regression" keyword is a lie and a skewing of the past. I unfortunately can't undo those changes myself due to a lack of privileges, but I hope someone who does will. And to asa, a heart-felt "**** you".
This is an enhancement, and is not a regression because it was purposely removed. Nobody is going to replace flags that were removed by a driver. Also, your profanity is not appropriate. Go read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html (and you're breaking all three of the commenting rules) and spare us the useless bugspam. To everybody else, sorry for the bugspam
mozbugs@gl00on.net, go read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html and feel free to send me email explaining how now that you've read and understand what is and isn't acceptible in Bugzilla and are willing to play by those rules, that I should re-enable your Bugzilla account.
Flags: blocking1.7-
Alias: mng
How close is MNG to being put back into Mozilla? Also what is left to be done?
Re: Comment 510 I'm re-iterating a few points made earlier, but some of this should be made crystal clear, especially to those whose impatience leads to bugspam. MNG won't be put into Mozilla/Firefox until some bugs are fixed up and the code that enables it is cleaned up. Someone must maintain the code if/when it is re-integrated. However, MNG inclusion won't even be considered until there is true reason to include it. According to some numbers I believe I saw at libmng or png.org/pub/mng, the number of MNG/JNG images ranges in the hundreds or the low thousands. Period. Worldwide. Ever. Almost all of these images are also set up as testcases, not as practical media on sites. Part of the reason for this is that the MNG spec and the mime types video/x-mng and image/x-jng are not registered with the IETF, meaning to say that they are not truly "accepted" or "standard" in an official documented sense. Thus, software and web servers aren't even configured to handle these filetypes for clients anyway. This lack of official recommendation and lack of support in a global perspective makes it pointless to include MNG because it generally will not be used in a general-use public web browser such as Mozilla/Firefox. This makes it cruft. Cruft is to be left out as much as possible to reduce size and improve performance. I believe if a larger pro-MNG movement were associated and international recommendation could be found, MNG inclusion would be certain in Mozilla/Firefox. And hey, once Opi updates the patch code (or I'll try building Firefox trunk and see if that works) I'll see the size difference between a normal build and a MNG (with PNG disabled so MNG renders PNG). That would be a compelling argument against the status of it as "cruft", if libmng could render PNG as stably as libpng.
Someone should have done this a long time ago. Rather than the typical "stop spamming this bug" post, I have an alternative approach. Please stop spamming this bug, and spam this newly created thread at MozillaZine instead: http://forums.mozillazine.org/viewtopic.php?t=115619
The Status Whiteboard (READ EVERYTHING BEFORE COMMENTING. PLEASE USE BUG #204520 TO COMMENT ON TECHNICAL ISSUES.) is quite misleading. If not on technical issues, what is this bug for? Advocacy? Moreover, concerning the first sentence of the Status Whiteboard, I doubt that everyone would read everything, in particular because many comments are obsolete or not interesting. It would be more useful to point to summaries (as this is done in some other bugs), like comment #511 (thanks for the explanations!) and comment #512.
Whiteboard: READ EVERYTHING BEFORE COMMENTING. PLEASE USE BUG #204520 TO COMMENT ON TECHNICAL ISSUES.
Asa: your abuse of power to censor unpleasant opinions just shows again why I said what I said (and why I still mean it).
There is a problem with Mozilla 1.8a3 and latest available libimgmng.so. I've submit the bug in the MNGzilla project page : http://sourceforge.net/tracker/index.php?func=detail&aid=1012060&group_id=92539&atid=601120 because I don't know if it is only specific to MNGzilla project. If some one could tell me... (Just to ass, with the same extension and Mozilla 1.8a2 there is no problems)
(In reply to comment #514) > Asa: your abuse of power to censor unpleasant opinions just shows again why I > said what I said (and why I still mean it). Please stop spamming this bug, and spam this newly created thread at MozillaZine instead: http://forums.mozillazine.org/viewtopic.php?t=115619
Attached file MNG (1.0.8) patch (trunk) bzip2 (obsolete) —
The long awaited and now existing new MNG patch. This patch is updated to libmng 1.0.8 (final) and works against trunk ... maybe this patch do not work with aviary (firefox/thunderbird 1.0).
Attachment #152566 - Attachment is obsolete: true
Asa you are a cancer inside Mozilla project. This is why good programmers keep away from Mozilla develop. Because you are like Hitler. Please kick Asa from Mozilla and other spammer like "us".
Asa you are a cancer inside Mozilla project. This is why good programmers keep away from Mozilla develop. Because you are like Hitler. Please kick Asa from Mozilla and other spammer like "us".
At this point I must interject. I was one of the first people to object publically to the CVS removal of MNG+JNG and have long been involved in Mozilla QA. Asa Dotzler is part of the heart and soul of Mozilla. Without him and those like him, this project does not exist. To imply that he is a "cancer" is pure idiocy. One Mozilla developer showed less-than-wise behavior in this matter, but even that fell far short of being a cancer. I want to see MNG+JNG returned to Mozilla. This bug is and always has been useless. I thought it was a terrible idea to reopen it in the first place (a new one should have been filed instead). Asa, please close this bug, and if possible let's ensure nobody can reopen or even comment on it. Enough is enough.
Let's let the stats speak for themselves: Bugs filed by asa@mozilla.org (userid 5003): 448. Bugs filed by try_2b@yahoo.com (userid 153222): 0. Account suspended for personal abuse. Gerv
(In reply to comment #518) > Asa you are... (In reply to comment #520) > At this point I must interject... (In reply to comment #521) > Let's let the stats speak for themselves... Please stop spamming this bug, and please spam this thread at MozillaZine, instead: http://forums.mozillazine.org/viewtopic.php?t=115619
Zachariah, why do you care about spamming this bug? It's a worthless bug at this point and anyone that's bothered by the spam could remove themselves from the bug and be no worse off. This bug isn't good for anything but the spam.
The focus of whoever wants to see MNG support adopted, really should be to develop a MNG extension. The update mechansisms added to Firefox allow this to be done and managed easily, and fixes to reach this goal if there's blocking problems, are much more likely to be accepted than trying to land MNG back in mozilla in the future. If such an extension is created, it can be listed at update.mozilla.org. Accept this as reality. Flaming people will get you nowhere and neither will pushing for this to be fixed in an unacceptable or opposed way. Period.
Damn ! I got every spam here three (3!) times in my mailbox and cannot remove myself from the cc list since I'm no longer listed (why ??). This bugzilla stuff does not work. Can one of the maintainers help me ?
(In reply to comment #525) > Damn ! I got every spam here three (3!) times in my mailbox and cannot remove > myself from the cc list since I'm no longer listed (why ??). This bugzilla stuff > does not work. Can one of the maintainers help me ? Remove your vote and you won't get it...
You're getting the repeat notifications because Bugzilla is having a difficult time processing the long Cc: list. The more of you that remove yourself from the Cc: list (or remove your vote which also acts as a Cc:) from this bug, the better that situation will get.
(In reply to comment #523) > This bug isn't good for anything but the spam. Asa, then what's the point to keep this bug open ? I'ld like to see MNG support back into mozilla (at least as a build option), but if it'll never happen, then this bug should be closed as "WONTFIX" (In reply to comment #525) > Remove your vote and you won't get it... Good way to decrease support for this enhancement request! :-) (Note: Asa, I really respect and appreciate all your hard work, and I'm sad about the personal attacks you've received)
Removing votes would, in the eyes of some people who look at bug statistics, make this bug look as if it were losing public support. To eliminate bugspam while preserving your votes, remove yourself from this bug's CC list and then turn off voter bugspam: 1. Go to your e-mail preferences page. http://bugzilla.mozilla.org/userprefs.cgi?tab=email 2. Turn off the "New Comments are added" and "CC list changes" checkboxes in the Voter column. 3. Submit the changes.
> Asa, then what's the point to keep this bug open ? I'ld like to see MNG support > back into mozilla (at least as a build option), but if it'll never happen, then > this bug should be closed as "WONTFIX" Yes, you are quite correct. It should be closed as WONTFIX.
WONTFIXing it might give the impression that MNG is no longer being considered. Perhaps it could be resolve as a dupe of bug 204520.
Greg, when MNG is in a state that would be acceptable for landing, a new bug "land the new, fully reviewed and approved MNG implementation" could be filed. This bug servers about -><- much value from a technical or even a process standpoint. I don't think it's a dupe of the disk space issue either. Isn't one of the conditions of taking the MNG implementation back into the tree that it not supply its own PNG implementation and use the one we have or be capable of replacing the one we have with a new one that's as performant and small? Either way, this bug serves little real purpose and those getting spammed by it are doing so by choice.
@the mng bug close discussion (asa & co.) Why don't ask the maintainer? Why speak about something without background information? Why don't give real information on the needs @the mng spammer Why you don't test the patches? Why I get no response? Why you don't help in the mng development? Why you don't spread mng images/animations in the www? @asa Mng builds on png that's why a libmng will also provide png support. There are some outstandings ... the latest patch seems to build but isn't invoked on a mng image, my own build work, but I've one tree for building and one for patching ... maybe there is a different for mng and the diff between both is 40MB, so it will take some time. Another problem is bug 250936 but nobody seems realy interested in this bug :-/ Anything else seems to be fine. In the next time I'll try to include libimgmng into libimg2 so we can reduce the overhead of the 2 jpeg's (see bug 204520 ). An option to user libmng for png's already exist. Greetings Alex//
Summary: restore support for MNG animation format and JNG image format → restore support for MNG animation format and JNG image format when MNG support is ready (if you're not the owner, please don't comment before it is)
resolving as invalid sounds like a better option than wontfix to me, actually. but i don't really like the sound of either. i agree it serves no real purpose, but such a resolution would just cause confusion.
There is at least one real propose: TRACKING the MNG support in mozilla main code i want to know when this is fixed, how and what is missing until we reach the fix, so closing this bug is cheating the propose of bugzilla. So please dont close this bug and keep posting about the evolution of MNG in mozilla. "spam" is a problem? yes, but its a side effect of a move that many people didnt like (whatever if it was right or not, each one have his own opinion) as for the "mng dislikers", accept that mng have alot of support, as in the past PNG and even JPEG had lot of support (and very little real use).
See bug #257263 for discussion of development of "APNG" format which is a simple animated PNG format. See bug #257197 for implementation of APNG in Mozilla.
Summary: restore support for MNG animation format and JNG image format when MNG support is ready (if you're not the owner, please don't comment before it is) → restore support for MNG animation format and JNG image format
First of all, I'd like to thank Alexander for the great work. I know how hard it is to work on such a large patch that touches so many files. Thank you for the updates in comment #533 and comment #517. I waited a while to comment again, so as to combine a lot into the same comment. (Hint, hint). PLEASE test the patch http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c517 if you want this to be sped along! Don't comment any longer unless you have information about your tests. Stop complaining and help. We have now advocacy about the fate of this bug. Please advocate on the forums. Alexander is the only one that should decide what happens to this bug. I'd like to remind people there are 700 votes on this bug. Closing it would most definately piss some people off. If we are going to close this bug, imho, we'd need to suggest where they can move their votes to. Advocacy doesn't go in Bugzilla. I remind people to use http://forums.mozillazine.org/viewtopic.php?t=115619 for discussions of a non-technical nature. Examples of GOOD comments: Comment #536 - "See also" comment Comment #515 - Testing information mozbugs: Please keep those personal discussions to private email or mozillazine forums. That is inappropriate for Bugzilla. I'm sorry you are angry. If you feel that you were unfairly treated, take it to the forums. I have known Asa for 4 years now, though, and in my experience he is very fair. > i want to know when this is fixed, how and what is missing until we reach the > fix, so closing this bug is cheating the propose of bugzilla I agree that it'd be nice, but seriously, how are we supposed to hear the progress if people keep posting unecessary crap. Nor should he be expected, as a volunteer, to keep us posted. But he does occasionally mention things and it gets drowned out by all the noise. What exactly do you want him to say? Things like its 70% done? In a software project, you just can't make that kind of statement, especially when a volunteer is doing it on his free time. Long progress updates would slow down development. Please, take this bitching to the forums http://forums.mozillazine.org/viewtopic.php?t=115619 so we can hear what he says. And yes, we do hear the spam by choice, but I'm actually more interested in what Alexander Optiz has to say and would like to stop hearing his stuff get drowned out. That's the only reason I haven't removed my CC. Thank you.
Whiteboard: COMMENTS GO HERE: http://forums.mozillazine.org/viewtopic.php?t=115619
Attached file MNG (1.0.8) patch (aviary) bzip2 (obsolete) —
This one should work better for Aviary.
Attachment #157850 - Attachment mime type: application/x-tar → application/x-bzip2
Attached file MNG (1.0.8) patch (aviary) bzip2 (2) (obsolete) —
Sorry, that one had an error in imgLoader.cpp.
Attachment #157850 - Attachment is obsolete: true
Attachment #134552 - Attachment is obsolete: true
Attachment #134552 - Attachment is obsolete: false
Combination of the attachment 152759 [details] [diff] [review] (Patch MIME sniffer code (2)) and attachment 156638 [details] (MNG (1.0.8) patch (trunk) bzip2), updated for AVIARY. (The way MIME declarations were handled somewhere in imgLoader weren't the same as the latest AVIARY.) This patch applies cleanly as of 20041016 and would allow one to use the --enable-image-decoders settings correctly, i.e. doing something like "-png,mng" to have libmng render PNG images and removing libpng from the code. (More efficient setup space-wise than having both enabled.)
Attached file MNG (1.0.8) patch (trunk) bzip2 (obsolete) —
update patch to latest cvs trunk The MIMESniffer Patch is a bit stupid ... if you want build from aviary with mng you also do not need it. And the problem of openening multible Windows if MIME not build in should be resolved on other places ... see bug 250936
Attachment #156638 - Attachment is obsolete: true
Comment on attachment 152759 [details] [diff] [review] Patch MIME sniffer code (2) Patch obsoleted by bug #250936. Another approach is required.
Attachment #152759 - Attachment is obsolete: true
Attachment #157908 - Attachment is obsolete: true
Attached file Mozilla-mng-1.0.8 (trunk-1.8a5) bzip2 (obsolete) —
patch sync'ed with current configure.in; no other changes.
Attachment #162568 - Attachment is obsolete: true
Attachment #164748 - Attachment description: Mozilla-mng-1.0,8 (trunk-1.8a2) bzip2 → Mozilla-mng-1.0,8 (trunk-1.8a5) bzip2
Attachment #164748 - Attachment description: Mozilla-mng-1.0,8 (trunk-1.8a5) bzip2 → Mozilla-mng-1.0.8 (trunk-1.8a5) bzip2
First (and long awaited) patch of mozilla MNG patch with MNG integrated into libimg. With MNG inside libimg2 we save a lot of diskspace (no need of doubled jpeg etc.) From this point on it is hard to make MNG extensions cause needed API's are not frozen and not inside the SDK. Hopefully I've packaged all correctly :)
Attachment #164748 - Attachment is obsolete: true
Great! But how do I enable JNG with this patch? I built with ac_add_options --enable-image-decoders=default,mng ac_add_options --enable-mng-type=MNG_BUILD_FULL_MNG but single JNGs cause the many-window-opening effect, while JNGs in a webpage just don't show up. And ac_add_options --enable-image-decoders=default,mng,jng does not work.
I forgott some small changes in the makefiles. So JNG(and PNG with MNG) should work again.
Attachment #166287 - Attachment is obsolete: true
Attachment #166329 - Flags: review?(tor)
update to trunk changes
Attachment #166329 - Attachment is obsolete: true
Attachment #169769 - Flags: review?(tor)
Sync patch with minor trunk change in libpr0n/src/imgLoader.cpp
Attachment #169769 - Attachment is obsolete: true
Attachment #172808 - Flags: review?(tor)
Attachment #166329 - Flags: review?(tor)
Change mime type to application/x-bzip2
Attachment #172808 - Attachment is obsolete: true
Attachment #172809 - Flags: review?(tor)
attachment 172809 [details] has illegal time stamp in mozilla/modules/libpref/src/init/all.js --- /mnt/mozilla_compile/mozilla/modules/libpref/src/init/all.js 2004-12-28 19:54:39 +0100 +++ ./mozilla/modules/libpref/src/init/all.js 2004-12-28 19:42:33 +0100
(In reply to comment #550) > attachment 172809 [details] and patch for mozilla/modules/libpr0n/src/imgLoader.cpp is malformed.
Fixed malformed patch and date. Libmng-1.0.9 has been released so this patch should be replaced soon with a libmng-1.0.9-based patch.
Attachment #172809 - Attachment is obsolete: true
Attachment #169769 - Flags: review?(tor)
Attachment #172808 - Attachment is patch: false
Attachment #172808 - Attachment mime type: text/plain → text/x-bzip2
Attachment #172808 - Flags: review?(tor)
Attachment #172809 - Flags: review?(tor)
Update to new libmng 1.0.9 Will do new size comparisions in the next days.
Attachment #173014 - Attachment is obsolete: true
Attachment #173326 - Flags: review?(tor)
Will MNG and JNG support ever be added to the 'main' builds of Mozilla and/or Firefox? I can justify telling people to stop using IE to view my website, or to update their copy of Firefox, but I can't really justify telling them to go download and install an obscure build of Mozilla that they likely would have no idea how to install.
As I understand, it's in the upcoming 1.8 (upon which the firefox 1.1 is built) -- so yes, eventually, once sm1.8/ff1.1 become stable, yeah.
I don't know where that "info" came from, MNG isn't even in CVS yet, and turning it on by default in Firefox/Thunderbird is by no means an automatic choice even if that were true. SVG will be built into 1.1, but disabled by default for now, but that's not MNG.
I probably misunderstood what "integrated" meant, then, see #553. I'm curious about those size comparisons Opi mentioned in February, too :)
Hey all, was long time to see progress on this patch, but there aren't many things to update ... ok, the last patch was crashy, couse I forgot a file to add to the Makefile.in. As all know, there won't be a Mozilla 1.8 cause Mozilla Foundation will concentrate on Firefox/Thunderbird. But there are some users who want the complete suite ... and so it will give a new complete Suite with the name ... (do I say it? ... hmmm no) ... ok the name stands but Mozilla Foundation will clear out all legal stuff before we can present the name. So I call it for the moment "Suite 1.0" ... yes it will start with 1.0. And the chance is higher then before to get MNG Support into "Suite 1.0" as in Mozilla 1.8. So here some answers to latest questions: @porta slime (#554): The chance to go into Firefox goes at the moment to zero. For Mozilla 1.8 it is zero, cause there won't be one. For "Suite 1.0" it may be around 50 percent. @Henrik Pauli (#555): Thats not true ... or you know more then me. @Henrik Pauli (#558): Integrated means, that mng is inside the libimg2.so (imglib.dll) and not in an extern file (libimgmng.so or mnglib.dll). That reduces the need of 2 JPEG code in libimg2.so and libimgmng.so. The size comparisons compares the size of libimg2.so as it is yet and the size if it is compiled with different mng configurations. But all last sizes are untrue, couse latest patch missed a file to compile (and so mozilla crashed on some MNG's). @Mike Connor (#556): That's right. Greetings Alex//
Attachment #173326 - Attachment is obsolete: true
Attachment #182736 - Flags: review?(tor)
No longer blocks: majorbugs
why zero for Firefox? :-(
Sync with recent trunk changes to configure.in and allmakefiles.sh
Attachment #182736 - Attachment is obsolete: true
(In reply to comment #560) > why zero for Firefox? :-( Because the FireFox development is driven by the same people who rejected it for mozilla even before 1.8 was canceled. Best chance of getting any spread of mng would be an FF extension as many FF users install extra extensions, one more will not be a problem and even a non tech user can install an extension. Once there are active users and sites using the format there will be more incentive for Mozilla Foundation to include it into the trunc.
> Best chance of getting any spread of mng would be an FF extension as many FF > users install extra extensions, one more will not be a problem and even a non > tech user can install an extension. AFAIK - Extensions can only be written in Javascript. Although it would be interesting to see such an implementation of a MNG decoder, it may not be entirely practical. Perhaps the Javascript could fetch the MNG file, parse the file, write frames to file, load the frames into the browser, and use javascript animations (as many are already doing currently). As the javascript would be executing from within an extension, I believe it should have authority to do all of the above. The advantage of this solution is that it would utilize the existing PNG support in Mozilla. The disadvantage being the difficultly of writing a new mng implementation and possible performance issues. Ultimately, such a solution would need to be replaced.
> AFAIK - Extensions can only be written in Javascript. they can be written in C++ too
Sync MNG patch with recent change to config/autoconf.mk.in
Attachment #162320 - Attachment is obsolete: true
Attachment #187747 - Attachment is obsolete: true
Sync with trunk; fix problem with Windows library linking.
Attachment #188747 - Attachment is obsolete: true
Attachment #190102 - Attachment is patch: false
Attachment #190102 - Attachment mime type: text/plain → application/x-bzip2
Sync patch with trunk. Added LIBXUL_LIBRARY=1 to mng Makefile.in
Attachment #190102 - Attachment is obsolete: true
Sync patch with trunk's configure.in
Attachment #191141 - Attachment is obsolete: true
Sync patch with trunk (change in allmakefiles.sh)
Attachment #191715 - Attachment is obsolete: true
Attachment #193120 - Attachment description: Mozilla-mng-1.0.9+ integrated (trunk 1.8b3 050818) bzip2 → Mozilla mng-1.0.9+ integrated (trunk 1.9a 050818) bzip2
Note that any patch will have to add entries back into prefs if/when bug 305435 is fixed.
Sync with changes to trunk's configure.in Undo checkin of patch from bug #305435 to trunk
Attachment #193120 - Attachment is obsolete: true
Sync'ed patch with MOZILLA_1.8_BRANCH. Use this patch to add MNG to a 1.8 branch checkout.
Attachment #193639 - Attachment description: Mozilla-mng-1.0.9+ integrated (trunk 1.8 050819) bzip2 → Mozilla-mng-1.0.9+ integrated (trunk 1.8b4 050819) bzip2
Attachment #193639 - Attachment description: Mozilla-mng-1.0.9+ integrated (trunk 1.8b4 050819) bzip2 → Mozilla-mng-1.0.9+ integrated (branch 1.8b4 050819) bzip2
Sync with libmng CVS (reduces footprint of "MOZ" and "WEB" configurations, removes MAGN chunk support from "WEB" configurations, restores 16-bit PNG support to "WEB" configurations)
Attachment #193428 - Attachment is obsolete: true
Sync with libmng CVS (reduces footprint of "MOZ" and "WEB" configurations, removes MAGN chunk support from "WEB" configurations, restores 16-bit PNG support to "WEB" configurations). Sync patch with yesterday's changes checked in to libpr0n/build.
Attachment #193639 - Attachment is obsolete: true
Attachment #193991 - Attachment description: Mozilla-1.9a-mng-1.09+ integrated (trunk 050825) → Mozilla-1.9a-mng-1.09+ integrated (trunk 050825) bzip2
Does not compile for me (VC 6, branch): D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT /cygdrive/c/mozilla/modules/libpr0n/build/n sImageModule.cpp nsImageModule.cpp C:\Programme\SDK\include\basetsd.h(32) : error C2371: 'INT32' : Neudefinition; u nterschiedliche Basistypen ../../../dist/include/jpeg\jmorecfg.h(178) : Siehe Deklaration von 'INT3 2' C:\Programme\SDK\include\wingdi.h(750) : warning C4005: 'BI_RLE8' : Makro-Neudef inition c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(135) : S iehe vorherige Definition von 'BI_RLE8' C:\Programme\SDK\include\wingdi.h(751) : warning C4005: 'BI_RLE4' : Makro-Neudef inition c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(136) : S iehe vorherige Definition von 'BI_RLE4' C:\Programme\SDK\include\wingdi.h(752) : warning C4005: 'BI_BITFIELDS' : Makro-N eudefinition c:/mozilla/modules/libpr0n/build/../decoders/bmp\nsBMPDecoder.h(137) : S iehe vorherige Definition von 'BI_BITFIELDS' make[4]: *** [nsImageModule.obj] Error 2 make[4]: Leaving directory `/cygdrive/c/mozilla/modules/libpr0n/build' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/cygdrive/c/mozilla/modules/libpr0n' make[2]: *** [tier_9] Error 2 make[2]: Leaving directory `/cygdrive/c/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/cygdrive/c/mozilla' make: *** [build] Error 2
Bernd: can you compile if you don't apply the MNG patch? There was a checkin of bug #223909 on Aug 26 that involves the JPEG encoder, where BI_RLE8 and other macros are defined. 84,87d83 < #if defined(XP_WIN32) && defined(IMG_BUILD_jpeg) < #include "nsJPEGEncoder.h" < #endif
Bernd: can you compile the same download if you don't apply the MNG patch?
The checkin involved the JPEG encoder but the macros are defined in the BMP decoder, so that is likely not to be the problem...
bernd: At line 179 of mozilla/jpeg/jmorecfg.h try changing typedef long INT32; to #ifndef INT32 typedef long INT32; #endif See bug#223909 which adds an include of a JPEG library that in turn includes jmorecfg.h.
I had time to build again: Your suggested fix didn't work just as you indicated it in comment#31 of bug #223909.
Rearranges order of #includes in nsImageModule.cpp to avoid doubly defining INT32 on Windows platforms.
Attachment #193992 - Attachment is obsolete: true
Comment on attachment 193991 [details] Mozilla-1.9a-mng-1.09+ integrated (trunk 050825) bzip2 Incompatible changes to allmakefiles.sh, configure.in, and libpr0n/build/nsImageModule.cpp have made this patch obsolete.
Attachment #193991 - Attachment is obsolete: true
Sync trunk patch with changes to allmakefiles.sh, configure.in, and libpr0n/build/nsImageModule.cpp that were recently checked in to bug #245684
At this point, is the patch to the point where it could be integrated into the build system with an --enable-mng option that was disabled by default? This would allow Firefox to not have it by default for size.
Andy: Yes, ever since February 2004 (commment #374), MNG doesn't compile by default with this patch, you need: --enable-image-decoders=default,mng to build MNG in your patched tree. Also, if you use --enable-image-decoders=default,mng,-png mozilla will use libmng to supply the PNG support, saving about 50k in footprint by eliminating libpng.
Removed some stray "*.orig" file references that were left in the "050902" trunk patch.
Attachment #194728 - Attachment is obsolete: true
glennrp: it's great that you continue to update the MNG/JNG patch. But should not the main goal be to get this reviewed and checked in? Otherwise you can unbitrot the patches forever (well, at least that might fully test Bugzilla's limits). Perhaps the SeaMonkey council can help? I remember that at least one of them was also unhappy with the removal of MNG. tor, if you still listen: it seems to me that all previous comments were taken into account some time ago, so is there any chance you might have time to look at this patch and review it? If you don't who else would be able to do that?
Comment on attachment 194884 [details] Mozilla-mng-1.0.9+ integrated (trunk 1.9a 050904) bzip2 tor: r? peter: opi already has two open requests (February and May 2005). I'll cancel those if I can.
Attachment #194884 - Flags: review?(tor)
Attachment #173326 - Flags: review?(tor)
Attachment #182736 - Flags: review?(tor)
Hi there I'm again and I thank glenn that he had done new patches. Now good news I've set up a tinderbox that builds SeaMonkey 1.0a branch builds with MNG enabled it uses the "Mozilla-1.8b4-mng-1.0.9+ integrated (branch 050830) bzip2" patch. You can find the builds on http://mozilla.itkombinat.de/tinderbox/
Update patch to work with recent change to configure.in on 1.8 branch
Attachment #194334 - Attachment is obsolete: true
Fixes memory overflow bug in MNG_NO_1_2_4BIT_SUPPORTED configuration
Attachment #198263 - Attachment is obsolete: true
Fixes memory overflow bug in MNG_NO_1_2_4BIT_SUPPORTED configuration; makes patch consistent with recent checkin of incompatible pref-winhooks* files in patch for bug #302479.
Attachment #194884 - Attachment is obsolete: true
Makes patch compatible with recent checkin from bug #245684
Attachment #198778 - Attachment is obsolete: true
Compensates for recent incompatible checkins involving automake.in and os2/browser.jst
Attachment #203443 - Attachment is obsolete: true
Compensates for 11/29 incompatible checkin to configure.in
Attachment #204125 - Attachment is obsolete: true
I've tried to build Firefox 1.5 with the mozilla-1.8b5-mng-051006 patch. Everything works okay, but in the end firefox.exe doesn't compile: Creating library firefox.lib and object firefox.exp mng.lib(libmng_chunk_io.obj) : error LNK2019: unresolved external symbol _mng_inflate_buffer referenced in function _create_chunk_storage firefox.exe : fatal error LNK1120: 1 unresolved externals make[4]: *** [firefox.exe] Error 96 Compiling on Windows XP with vc7.1.
I've tried to build Firefox 1.5 with the mozilla-1.8b5-mng-051006 patch. Everything works okay, but in the end firefox.exe doesn't compile: Creating library firefox.lib and object firefox.exp mng.lib(libmng_chunk_io.obj) : error LNK2019: unresolved external symbol _mng_inflate_buffer referenced in function _create_chunk_storage firefox.exe : fatal error LNK1120: 1 unresolved externals make[4]: *** [firefox.exe] Error 96 Compiling on Windows XP with vc7.1.
Fixes problem with unsatisfied reference to mng_inflate_buffer() on 1.8 branch
Attachment #198777 - Attachment is obsolete: true
Fixes problem with unsatisfied reference to mng_inflate_buffer() on trunk.
Attachment #204902 - Attachment is obsolete: true
Instead of putting new patches in this bug every few days, how about moving the patches to mozdev or sourceforge or libpng.org/mng and keep current versions up there. It doesn't seem like keeping 100 patches in a bug is really what bugzilla was designed for.
I think it would be even better if it was stored in the current CVS HEAD, but failing that, why move it off into obscurity?
I don't see that happening any time soon and I'd say a bugzilla bug is pretty obscure to start with, so it seems like putting it somewhere else wouldn't be so bad.
I agree that this patch is a bit too large to be updated every few days, perhaps posting the Mozilla part only and not libmng itself would be a better idea. (One could see it as a testcase for Bugzilla, though. ;-) ) The code that needs review and could disturbe any of the other code in CVS are really only a few lines. You are one of the people who could review it and the sooner you do that the sooner this bug could be resolved...
Comment on attachment 204990 [details] Mozilla-1.8-mng-1.0.9+ (branch 051204) bzip2 tor: r?
Attachment #204990 - Flags: review?(tor)
Attachment #194884 - Flags: review?(tor)
Comment on attachment 204990 [details] Mozilla-1.8-mng-1.0.9+ (branch 051204) bzip2 This patch is now made obsolete by a new patch posted at mngzilla.sf.net in the Download/mngzilla-patches area. Please interpret the "r?" flag as a request to review the patch over there.
Attachment #204990 - Attachment is obsolete: true
Attachment #204990 - Flags: review?(tor)
Attachment #204991 - Attachment is obsolete: true
Attachment #134552 - Attachment is obsolete: true
Attachment #124907 - Attachment is obsolete: true
What's needed to restore for MNG support to the trunk?Does the recent patches have any serious problems? If bug 204520 is the big problem, prepare "--enable-mng" option in configure script and it turns off by default. If users want to test MNG featute, they have to turn on.What I mean is that this option is categorize as "Components and Features" at http://webtools.mozilla.org/build/config.cgi If system has a valid libmng, configure script adds MNG feature automatically. This is the another idea. Maybe the size is not so bigger than that without MNG feature. Sorry for idea only.
Takanori: This feature has been present in the patches for nearly two years. See comment#374 and comment #585. To demonstrate this to yourself, apply the latest patch (for the trunk or the 1.8 branch, as appropriate) from mngzilla.sf.net, run autoconfig, and build. Notice that the executable is the same as without the patch, and that there is no MNG support. Then put --enable-image-decoders=default,mng,-png in your .mozconfig file (you must do it with a text editor because the "configurator" doesn't have a checklist for decoders) and build again. Notice that the image library is about 120kbytes larger and that you have full MNG support.
Blocks: 323860
I've separated the mng patch into one that adds the mng library and another (with trunk and branch versions) that adds mng "glue" to libpr0n and various configuration files, as Peter suggested in comment #603. You need both the "add-libmng" patch and the appropriate "mng glue" patch. The "add-libmng" patch is not likely to be subject to bit-rot, while the "glue" patches will probably be updated frequently. The patches are available at http://mngzilla.sf.net in the DOWNLOAD area, mngzilla-patches package.
Flags: blocking1.9a1?
Blocks: 326817
Our research lab makes MNG movies of bio-molecules. We plan to make these publically available. MNG seems like it is probably the best format for us. We would like to recommend your browser for our web page, but presently mozilla does not support MNG format. http://www.chem.ucsb.edu/~sheagroup/. Feel free to contact me at aij@physics.ucsb.edu
My vote is to add MNG support to Firefox by version 3 (and Seamonkey). This niche is currently being filled by the proprietary SWF (Flash) format and aging GIF format. Some say there aren't many MNG creation tools and other browsers support it. The situation is very chicken and egg, and Firefox support would help things out a lot, especially considering that Firefox is #2 in browser market share measurements. I also posted in the forum topic for this bug report. http://forums.mozillazine.org/viewtopic.php?p=2361777#2361777
Flags: blocking1.9a1? → blocking1.9-
Glenn, I assume that a lot of work has been done on the patch in the months that were quiet on this bug-report. May be you could possibly post a recent version of the glue-code in a patch format (non-compressed) over here in bugzilla, and ask for the review? (Please, do post the glue-code non-compressed so that everyone can easily see the changes it makes with default bugzilla patch-browser.) Also, some update on major changes made in the last year period might be appropriate here, too. Cheers, Constantine.
(In reply to comment #611) > Glenn, > > I assume that a lot of work has been done on the patch in the months that were > quiet on this bug-report. No, nothing other than keeping up with bit-rot. Otherwise it is working fine and doesn't need any work. >May be you could possibly post a recent version of > the glue-code in a patch format (non-compressed) over here in bugzilla, > and ask for the review? (Please, do post the glue-code non-compressed > so that everyone can easily see the changes it makes with default > bugzilla patch-browser.) The glue-code patch is quite fragile, easily broken by changes to configure.in, allmakefiles.sh, etc. If I were to post it here I'd be back in the mode of last year, having to update it often, as I do over on mngzilla.sf.net. > Also, some update on major changes made in the last year period might be > appropriate here, too. There were none.
(In reply to comment #612) > > I assume that a lot of work has been done on the patch in the months that were > > quiet on this bug-report. > > No, nothing other than keeping up with bit-rot. Otherwise it is working fine > and doesn't need any work. Why don't you ask for a review then, if there is nothing more to be fixed? > >May be you could possibly post a recent version of > > the glue-code in a patch format (non-compressed) over here in bugzilla, > > and ask for the review? (Please, do post the glue-code non-compressed > > so that everyone can easily see the changes it makes with default > > bugzilla patch-browser.) > > The glue-code patch is quite fragile, easily broken by changes to > configure.in, allmakefiles.sh, etc. It's not like you have to update it every week here, you can update it here every so often, and the reviewer would assume that the patch still applies (and if the patch doesn't apply, the reviewer would then go to the sf.net page for the otherwise identical patch but which applies to most-recent tree). Having some more or less recent patch in bugzilla would make the review process easier, IMHO. As far as I understand, no-one is reviewing the patch now, because there is simply no official request and no official patch to review. >If I were to post it here I'd be > back in the mode of last year, having to update it often, as I do over > on mngzilla.sf.net. How will it ever be integrated into the main mozilla source-tree if it's not posted here, and doesn't get a review/superreview from someone? Alternatively, is it the plan to never have it in the main tree? I think something must be done to fix the situation; posting a patch here and requesting a review might be the first step...
>there were none. Oops, I forgot. There were some minor mods required for CAIRO support. >Why don't you ask for a review Please suggest a reviewer.
(In reply to comment #613) > How will it ever be integrated into the main mozilla source-tree if it's not > posted here, and doesn't get a review/superreview from someone? Alternatively, > is it the plan to never have it in the main tree? I think something must be > done to fix the situation; posting a patch here and requesting a review might > be the first step... As an outsider to this whole process, may I just say that I would be saddened if it did not somehow make it into the main tree. My entire goal (and reason for being on this CC list) is for MNG support to exist in some future version of Firefox that I download (pre-built, bundled -- I haven't been building by hand, though I probably could), and thus have it be available to a great many people (who couldn't build it if they wanted to, many of them -- for lack of know-how and tools, even if not for lack of the option). I hope that getting this patch into the main tree would provide that for me, even if there were then future steps to get it there. So, whatever it does take, I hope that getting this patch into the mozilla tree will happen. I sense a bit of frustration from multiple perspectives on this, and I'm enough of an outsider that I don't know what the frustration factors are, exactly (or even if my sense is correct, really), but I do hope they'll be worked past and that I can see MNGs within Firefox sometime soon (whatever "soon" might mean).
>So, whatever it does take, I hope that getting this patch into the mozilla tree >will happen. I sense a bit of frustration from multiple perspectives on this, >and I'm enough of an outsider that I don't know what the frustration factors >are, exactly (or even if my sense is correct, really), but I do hope they'll be >worked past and that I can see MNGs within Firefox sometime soon (whatever >"soon" might mean). I too would love to see the official release of Firefox with MNG. However, I do not see this happening any time within the near future. In the meantime, I would love to see someone take this work and make an extension out of it. I have noticed that extensions that are often downloaded seem to make their way into newer versions of Firefox. Perhaps that is the solution to getting it recognized since 812 votes seem to have no impact.
> My entire goal (and reason > for being on this CC list) is for MNG support to exist in some future version > of Firefox that I download (pre-built, bundled -- You can get prebuilt binaries from mngzilla.sf.net, for FF 1.5, 2.0, and 3.0. I use the 3.0 build by "auenf" as my regular browser. It uses the MNG library to provide PNG support.
(In reply to comment #617) > You can get prebuilt binaries from mngzilla.sf.net, for FF 1.5, 2.0, and 3.0. > I use the 3.0 build by "auenf" as my regular browser. It uses the MNG library > to provide PNG support. That's nice to know, and perhaps I'll go do that... However, it doesn't really solve the problem for me. For me, the problem is not so much as a consumer of content, but as a producer of content. I want _everybody_ who has a certain version of FF or later, and/or who has a certain extension to it (that solution might actually work for me -- though built-in would be better, of course), to have this. I want this to replace GIF for animated images. It can't do that without browser support. Browser support has to start somewhere. I'd think that the mozilla project would be a good place for it to start. I really hope that my comments here will be taken solely as encouragement to make this happen, somehow. I'd really like to see it. I don't know how much I can help beyond encouragement, but if there's something you think I might do, please do feel free to contact me directly.
Could someone provide a list of what is blocking us from re-implementing MNG? Thanks!
(In reply to comment #619) > Could someone provide a list of what is blocking us from re-implementing MNG? > Thanks! I'd like to know that also
copied from newsgroup posting: >> Sarreq Teryx wrote: >> I know this has probably come up at some point, but will MNG/JNG or APNG >> support be implemented any time soon (without having to resort to a >> plugin)? mostly I'd just like to see JNG, the lack of compression in PNG >> really limits my use of them in my web pages, but I'd also like to >> replace my animated GIFs, I hate having to create a new copy of each just >> so I can change the background color of my pages (anti-aliasing). > Eli Friedman wrote: >I can't really see why you'd want to use JNG; it's exactly the same >compression as plain old JPG. the point being JPEGs with an alpha-channel, or alpha-channeled PNGs small enough to use on a web page and not take forever to load. Tell me this, over the course of a day's web browsing traffic, what's more bandwidth efficient, having users download a compiled copy of Firefox with JNG support then lots of 88.5KB images, or leaving out JNG and having them download lots of 628.74KB images (example used here: http://sarreq.elflord.net/mngpng/)? just because the bandwidth is there doesn't mean it needs to be saturated, and also think of all the hosting sites who give you a limited amount of total traffic. Yes this particular wish could be fulfilled by (for shame) MS's HD Photo format, but also, there's no browser support for that either (except in IE7, as long as you're running either XP with .Net 3 and WIC or Vista). > MNG/JNG support is not planned. See > https://bugzilla.mozilla.org/show_bug.cgi?id=18574. saw it, saw nothing but "We don't want to do it" with no really good reasons behind that 1. code bloat ---> oooh wow, 542KB (from http://gjuyn.xs4all.nl/libmng/download.html?cat=25) on top of 36MB (2.0.0.3 rc1 source package compressed, wasn't going to DL to check uncompressed), doesn't seem that much of a bloat to me. And stripping the duplicate JPEG and PNG code would make it even smaller. 2. An XPI/plugin exists to do just that ---> An XPI needs understanding of how to compile and merge the sources, or an alternate build which most people won't realize exists, while a plugin requires the use of the embed/object tag, and doesn't render the alpha-channel properly, and both the XPI and the plugin need to be widely known about for them to be used, which they're not, so neither are particularly appetizing options 3. MNG-LC/VLC or other subset may find their way in ---> sorry but a subset of certain formats is a joke, this being one of those jokes 4. GIF, Flash and SVG cover this feature ---> GIF is what those of us who want MNG support are trying to replace, Flash, again, needs a downloaded plugin (which firefox does know how to find on it's own, granted) and embed/object tag, and then SVG, point me to a program which actually outputs the code to duplicate the functionality, I can't seem to find any myself, and even so, again, NO COMPRESSION 5. MNG/JNG is not w3c recomended ---> but then neither are GIF or Flash, they're just ubiquitous 6. MNG/JNG is not used much ---> Well, I think there's a good reason for that, the browser support doesn't exist, woohoo! The same could have been said about JPEG, GIF, PNG, SVG and Flash when they were first proposed for browser use. I really hate using this word, but DUH! 7. there's no one to maintain the code ---> FIND someone, out of the millions of programmers on the planet, I'm sure someone exists that would be willing to take care of it (don't look at me, I don't even know javascript that well) 8. GIF patent issues are no longer a problem to GIF use ---> So what, that has nothing to do with what the format is capable of, GIF is still limited to 8bit paletted color with one of those used as the transparency mask, being out of under Unisys's foot doesn't fix that. > APNG support is planned for Gecko 1.9/Fx 3.0, but of course using it on > the web would be pretty stupid in most > cases since no other browser will support it. It's mostly intended for > XUL/chrome stuff. Work is ongoing in > https://bugzilla.mozilla.org/show_bug.cgi?id=257197. Which is fine, but again, no more compression than regular PNGs, and since we're talking multiple frames in each file, even larger APNGs. As for lack of browser support, if a feature is used enough it will spread to the other browsers, how long did Firefox support PNG before it was supported in Internet Explorer (without javascript workarounds)? As for use in XUL/chrome, you're willing to have supersized images for skins/GUI elements over smaller images and an insignificant amount of code bloat? where's the thinking there? Adoption of a format, no matter what it is, takes the first larger competitor to say it's a format wanted by the web developers and end-users. Konqueror supports MNG/JNG, but it's not exactly one of the larger competitors.
We aren't going to add back MNG support. This bug was left open because certain people didn't want it closed but it really just isn't going to happen and people need to realize that. We'll be adding APNG support shortly and we'll look at other image formats down the road.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 18 years ago
Resolution: --- → WONTFIX
(In reply to comment #621) some things to say: - there aren't good reason to keep out the patch of Glenn Randers-Pehrson. - reading all the histry of this bug, I learned that much time ago, some of the drivers decide to keep out MNG code arguing of size growing - lot of user want this feature, looking at the number of votes (831), maybe the most voted bug of mozilla - periodically new user post an ask to add back MNG - can normal GPL users, not drivers, decide where Mozilla should go, also respecting all the prerequisite for code manteining and patching? Wake up, we aren't in a democracy. Constantine A. Murenin or someone else, please suggest a reviewer for the Glenn patch.
(In reply to comment #623) > - can normal GPL users, not drivers, decide where Mozilla should go, also > respecting all the prerequisite for code manteining and patching? Normal GPL users? Mozilla is built on top of the MPL... not sure what GPL users are. > Wake up, we aren't in a democracy. Yes.. and that is why your vote doesn't matter... > Constantine A. Murenin or someone else, please suggest a reviewer for the Glenn > patch. I'm the module owner and we've been over this. People tried to go over my head and got shot down. Please let this bug finally die.
Look people. There is no democracy. It has been made abunduntly clear that this is a personal issue with Stuart and he doesn't want MNG in Firefox for whatever reasons. Maybe he doesn't like the guy who developed MNG, who knows. The point is that no one has offered a rational explanation of why MNG shouldn't be included, and they have made it abunduntly clear that they are not going to explain it in the future either. If you want to agitate for MNG, you need to agitate to have Stuart replaced as the module owner.
Þe next move is to now go to distributions ænd forks. We should now start opening bug reports wið þe patches in distributions in Linux, BSD, etc. ænd forks such as IceWeasel. To þæt end, Ich just filled out a feature request for Debian Linux ænd will post þe bug number here soon.
Þe bug report for þis in Debian linux is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414936
(In reply to comment #621) > {{ JNG support }} Yes this particular wish could be fulfilled by (for shame) > MS's HD Photo format, but also, there's no browser support for that either > (except in IE7, as long as you're running either XP with .Net 3 and WIC or > Vista). As explained above, Microsoft has already taken care of a JPG w/ Alpha Channels format, and it's already supported by the latest-greatest software out there. People are already using it, so there's really no point now in introducing JNG. Let's just support HD Photo and call it a night. Firefox is not responsible for makeing image formats popular by supporting them. I mean, it's not like web developers built their websites based on what works on end user's browsers. They build websites around what MSDN says. PNG is just a fluke.
(In reply to comment #625) > Look people. There is no democracy. It has been made abunduntly clear that this > is a personal issue with Stuart and he doesn't want MNG in Firefox for whatever > reasons. Maybe he doesn't like the guy who developed MNG, who knows. The point > is that no one has offered a rational explanation of why MNG shouldn't be > included, and they have made it abunduntly clear that they are not going to > explain it in the future either. If you want to agitate for MNG, you need to > agitate to have Stuart replaced as the module owner. > Then perhaps when he moves on this can get committed? In my opinion, this is something that should have been made part of Mozilla YEARS ago. There is little to no chance of MNG/JNG gaining popularity on the web until Mozilla bundles support in. Personally, I find it sad when politics and personal problems prevent good code from being checked in. Code should be judged on merit alone.
(In reply to comment #625) > Look people. There is no democracy. It has been made abunduntly clear that this > is a personal issue with Stuart and he doesn't want MNG in Firefox for whatever > reasons. Maybe he doesn't like the guy who developed MNG, who knows. The point > is that no one has offered a rational explanation of why MNG shouldn't be > included, and they have made it abunduntly clear that they are not going to > explain it in the future either. If you want to agitate for MNG, you need to > agitate to have Stuart replaced as the module owner. > Then perhaps when he moves on this can get committed? In my opinion, this is something that should have been made part of Mozilla YEARS ago. There is little to no chance of MNG/JNG gaining popularity on the web until Mozilla bundles support in. Personally, I find it sad when politics and personal problems prevent good code from being checked in. Code should be judged on merit alone.
There is a problem that exists for at least 829 web developers, that of producing open, portable, lossless, native, 32-bit RGBA raster animations. Glenn and 36 other contributors produced a standard which seeks to solve that with respect to a variety of use cases. The binary size for the implementation would constitute a not insignificant increase to the binary size of libpr0n-derived products. Stuart and Vladimir produced a minimal standard specifically with respect to Mozilla UI. This standard contains at least least one (minor) conflict with the PNG specification. It is unheard of outside of Mozilla. The power structure in effect is irrelevant as long as we all agree that: * SVG, GIF, Flash, embedded video and Javascript-driven image-swapping are not satisfactory in many (minority) cases. * Firefox should provide a solution to this issue for developers. * That solution should be "best practice", with a view to cross-browser adoption. * Until broadband penetration increases, any increases in the download size could harm adoption, most critically for Firefox on Windows. I don't think marking this as WONTFIX constitutes closure on the issue. Either MNG needs to come back or APNG needs to be ratified by the wider community. Even if APNG was ratified by the wider community, this should not necessarily shut the door on MNG in libpr0n as download times drop or the value of MNG support increases.
(In reply to comment #630) > (In reply to comment #625) > > Look people. There is no democracy. It has been made abunduntly clear that this > > is a personal issue with Stuart [...] > > Then perhaps when he moves on this can get committed? Whatever issues Stuart Parmenter has, it's not just him. As he just said, this debate was taken to other people, and they also rejected the idea of MNG - see for example Mike Connor's comment 474 especially point c. "Content that 90% of the web doesn't support isn't going to get created in any substantive way. MNG has the advantage of being more ideologically pure than Flash etc, but if people aren't using it, its cruft, and that's the reality. Given the choice, we'd be much better off bundling Flash with Firefox based on the "size vs. usability boost" equation. I realize lots of people don't like Flash for a myriad of reasons, but users don't care." > There is little to no chance of MNG/JNG gaining popularity on the web until Mozilla bundles support in. And the main argument against is that even if Mozilla bundles support, they will still not gain popularity as most websites aren't going to bother with something that doesn't work in IE.
Re: 632 and through that 464 Which is pretty much the only decent argument in this whole debate, but: - PNG wasn't popular, still isn't too popular, but apparently MS caved in and finally supports alpha in it now and that might give it a boost -- and even before that, quite an amount of people employed the format for the awesomeness of it (a word which here means "full 8-bit alpha while true colour and lossless") -- in this sense, what is there that makes MNG/JNG impossible to gain popularity, at least among the OSS world? (someone mentioned that Konqueror already supports it, I'm not sure if as a result Safari does too, but that would be cool) And if it takes off, MS might follow suit again. - noone has ever heard of APNG, so it makes me wonder why it's better than MNG/JNG for _UI_ uses, because I seem to remember that the latter are at least standards that have been around for years and have (been having) tools (for a while) with which to create them.
There is very little value to having MNG support; it's interesting that people immediately think that there are "personal reasons" for WONTFIX'ing this bug. The only personal reason that's left is that this bug should have been left alone years ago, but instead it's lived on in a zombie state. I assume it gets personal when someone's decisions (with agreement from the wider project drivers) keep getting second-guessed. That said, there are technical reasons for why MNG is not in Firefox right now, indeed why MNG is not anywhere on the web right now. The spec as it is suffers from many of the same problems as SVG (but with far less money behind it) in that it's bloated and tries to do too much -- not to mention the utter lack of tooling, and given the spec's complexity, the virtual impossibility of actually creating any useful fully-general tooling around MNG. MNG is dead; it was too much to bite off all at once and attempted to ride on the success of PNG. PNG solved a specific concrete problem that the web faced; APNG tries to solve another well-defined and specific problem. "open, portable, lossless, native, 32-bit RGBA raster animations" is /not/ a problem that the web faces right now (and it certainly wasn't 5 years ago); indeed, SVG has a higher chance of solving this at the moment despite a host of other problems. Download size is at this point not very relevant; if there was a reason to support MNG, it could be made to fit. But I'll reiterate: MNG is dead, just like VRML and many other technologies are dead. Good ideas or not, they did not have enough momentum to propel them to some sort of self-sustaining growth. Sure, they'll always be kicking around in some dusty corner of the net, but for all intents and purposes they are dead. Please let this bug finally die gracefully; there are plenty of new technologies out there to get behind... there is no reason to keep trying to resurrect this one.
So to summarize: 1. Size issues. Not the actual reason. Maybe it was at the beginning, but hasn't been a valid reason for a long time. 2. No one will use it anyway. A somewhat plausible reason on it's own, but still not a very good reason - how many other things does Firefox support that IE never will? Why don't we take those out? 3. MNG is just a dead format because it's just too complicated, and has no financial backing, and no one else cares anyway. This seems like a good enough reason to me, but is that official from the MNG group, or is it just the official opinion of the devs responsible for Mozilla (which is frankly still good enough for me)? It seems like this whole thread just keeps going on and on, because we get some really bad emotional excuses for leaving it out, without any real rational ones. To make matters worse, there was a condition set up for it to be reincluded by default, and when that condition was met, it was still stone walled. That kind of behavior tends to lead to bitter feelings, and hardening ones. If Comment #634 is really the final word on why this is being left out, can we all accept that, and admit that mistakes were made in how this was handled and just let it go?
> - can normal GPL users, not drivers, decide where Mozilla should go, also > respecting all the prerequisite for code manteining and patching? No, if you're not part of the Qabal that run this project, your opinion means nothing. The Mozilla / Firefox / Seamonkey / Whatever drivers / leaders have NEVER given a rats ass about input from the community. I've been following this project since shortly after it's inception (eg, since 1997 or so) and it's always been that way. Honestly, if you're not happy with the direction of Firefox / Seamonkey / Thunderbird / what-have-you, the best thing to do is just fork it... or else accept things the way they are. The "inner circle" just are not going to acknowledge any need to respect the wants and needs of the community, period.
(In reply to comment #635) > 2. No one will use it anyway. A somewhat plausible reason on it's own, but > still not a very good reason - how many other things does Firefox support that > IE never will? Why don't we take those out? Please, don't give these guys any ideas. I'd hate to see any more features taken out for some equally asinine reason.
It's a zombie bug, but there remains the open issue that /some/ lossy format with variable alpha is needed, and has been for many years. APNG is not a solution for that. It would be rather depressing to see FireFox have to be a follower and not a leader in response to Microsoft's HD Photo which will cover this capability.
(In reply to comment #622) > We aren't going to add back MNG support. This bug was left open because > certain people didn't want it closed but it really just isn't going to happen > and people need to realize that. We'll be adding APNG support shortly and > we'll look at other image formats down the road. I'm sorry, it seems from what I've read on this page that there's a large majority of people here that don't want it closed, not just certain people. And as far as I can see, APNG is only good for XUL/Chrome. (In reply to comment #624) >> Wake up, we aren't in a democracy. >Yes.. and that is why your vote doesn't matter... Wow, what an answer, maybe you could be president >> Constantine A. Murenin or someone else, please suggest a reviewer for the >> Glenn patch. > I'm the module owner and we've been over this. People tried to go over my > head and got shot down. Please let this bug finally die. If there were real, substantial, non-political reasons to let it die, I'm sure it would have by now. all I see is "nononononono, I'm not listening", with no valid reasoning behind it. (In reply to comment #628) > Firefox is not responsible for makeing image formats popular by supporting > them. I never said it was, but it does have enough of the browser market to influence things along. > I mean, it's not like web developers built their websites based on > what works on end user's browsers. They build websites around what MSDN > says. PNG is just a fluke. If that's so, why do we even bother using Firefox? I know plenty of my pages have problems rendering properly under IE (until I link in some form of script to accommodate that). As for PNG being a fluke, maybe, but I don't believe it really is. (In reply to comment #630) > Personally, I find it sad when politics and personal problems prevent good > code from being checked in. Code should be judged on merit alone. Absolutely (In reply to comment #631) > * SVG, GIF, Flash, embedded video and Javascript-driven image-swapping are not > satisfactory in many (minority) cases. GIF is not satisfactory period and hasn't been for a good few years. Flash for that matter is only really satisfactory if you're writing a very complex interactivity based interface, which does so better than HTML or Java/JS, but not for simple site animations or alpha-channeled static images, if you want to talk about bloat, there we go right there. I can't comment on SVG, I've not found a good program which supports it except for commercial ones. > * Until broadband penetration increases, any increases in the download size > could harm adoption, most critically for Firefox on Windows. realistically, a hundred or so KB on top of 5.7MB (v2.0.0.2) is not going to hurt anything, the possible 1-2MB worth of APNGs that may end up shipping with v3 might though. > I don't think marking this as WONTFIX constitutes closure on the issue. Absolutely not, it just constitutes more ignorance of the community at large.
(In reply to comment #634) > "open, portable, lossless, native, 32-bit RGBA raster animations" is /not/ a > problem that the web faces right now (and it certainly wasn't 5 years ago) I disagree. Even in 2001, Windows XP had 32-bit RGBA raster animations in its UI. The current state of the art today is, potentially, lossless RGBA everywhere. It's not a large omission, but it still exists: sometimes web app UI is best served by an animation, and current capabilities warrant something along these lines. SVG, as you note, has problems that make it unsuitable. It will remain unsuitable for at least the next couple of years, probably longer. > But I'll reiterate: MNG is dead, just > like VRML and many other technologies are dead. VRML is a dreadful analogy. It borders on FUD to bring it up in this context. MNG has never featured in a Firefox release and therefore could not be expected to reach the momentum for self-sustaining growth. If MNG was shipped in FF3, you would undoubtedly see it in significant use within 6 months, driven by the blogosphere and "Web 2.0" sites.
> not to mention the utter lack of tooling, and given the spec's complexity, the > virtual impossibility of actually creating any useful fully-general tooling > around MNG I can point out 4 programs currently on my computer which work with MNG (Jasc AnimShop, XnView, IvanView, Ashampoo PhotoComander), two of which supports JNG also (AShampoo Photo Commander, IvanView) , whereas I can only think of adobe and PSP which work with SVG, and not even for animation.
Sorry, my comment #628 was complete sarcasm. >> Firefox is not responsible for making image formats popular by supporting >> them. > I never said it was, but it does have enough of the browser market to influence > things along. From day one, browsers have been a huge influence on the file formats people develop and use. Like it or not, IE and Netscape completely defined HTML, Javascript, and solidified the use of JPG and GIF.. And PNG. >> I mean, it's not like web developers built their websites based on >> what works on end user's browsers. They build websites around what MSDN >> says. PNG is just a fluke. > If that's so, why do we even bother using Firefox? I know plenty of my pages > have problems rendering properly under IE (until I link in some form of script > to accommodate that). > As for PNG being a fluke, maybe, but I don't believe it really is. Right. Web developers DO build their websites based on what works in the end-user's browsers. Firefox holds a huge share of those users, and MANY web developers are looking for an excuse to support OPEN technologies through Firefox's support of them. There are several thousand developers, right now, waiting for the implementation of MNG and JNG support so they can utilize this technology for the simple sake of using them. It wasn't until Firefox's support of PNG that Adobe Photoshop supported the PNG file format. Apple Quicktime supported PNG for a while, but it didn't end up in Photoshop until Firefox (feel warm-and-fuzzy). Until Firefox supports JNG (and MNG), Adobe simply refuses to support it themselves. And once they support Microsoft's HD Photo, they may be even less inclined to support JNG there-after. Email Adobe and ask them yourself! What we need is a Windows software developer to create an MNG animation suite. Contact the author of "GIF Construction Set" at Alchemy Mindworks <www.mindworkshop.com> and ask if he'd write "MNG Construction Set". He was the active forerunner of GIF89a support, loving the idea of animated graphics, but hated all the legal hassle. I'm willing to bet he'd embrace MNG if his contribution and "vested interest" meant Firefox may actually support it.
expanding on my last comment (#641) Oh, and then there's these: viewer/converters - http://www.libpng.org/pub/mng/mngapvw.html editors - http://www.libpng.org/pub/mng/mngaped.html
(In reply to comment #642) > What we need is a Windows software developer to create an MNG animation suite. > Contact the author of "GIF Construction Set" at Alchemy Mindworks > <www.mindworkshop.com> and ask if he'd write "MNG Construction Set". He was > the active forerunner of GIF89a support, loving the idea of animated graphics, > but hated all the legal hassle. > I'm willing to bet he'd embrace MNG if his contribution and "vested interest" > meant Firefox may actually support it. He already has MNG/PNG Construction Set - http://www.mindworkshop.com/alchemy/pngpro.html Animation Workshop - http://www.mindworkshop.com/alchemy/animwork.html
Is somebody maintaining seamonkey|firefox forks with MNG support and with binary packages readily downloadable? Something like a "Mozilla Advanced Project", where everything is included in the browser which (1) is implemented, (2) requested and (3) does not make the browser unstable? Maybe also some Linux distribution maintains a better version of seamonkey|firefox.
those that say that mng isnt used forgot that it's their fault!! mng was made mostly for the web, and mozilla kill it. nmg and this bug is open since 1999 (YES, 7 YEARS AGO!!)... if firefox did add (and didnt removed later) mng support back then, right now the use of mng would be alot higher, by removing the mng they effectively halted their spread, until today... all this dragging along gave the opportunity to MS to catch up and create a new format and flash to be required all over the place. those saying that flash can replace mng, please give the a flash plugin for PPC, for x86_64, for mips, etc... the world isnt just windows you know! Mozilla blow up their opportunity back then and still do it now, the drivers dont like the mng that its open and works and prefer drag for 7 years a problem and work with a unsupported third part plugin (flash) that only recently (and with some luck) started to work fine (ie: crash's less) in firefox and, again, isnt open enough to work in every machines to make thing worst, try to hijack the png with a same stupid idea behind the animated gif. mng was trim down to allow the restore of its code to firefox, a maintainer of the glue code was found, the original issues were solved only to be ignored by mozilla, we all felt cheated and after 7 YEARS the problem is still here! mozilla is becoming very arrogant to its users, specially their oldest support base, the free software community and advanced web designers. all this bad management are making the iceweasel fork, and the alternatives opera and konqueror, becoming more attractive... all this is too stupid to be true!! ps: if votes are useless, remove then, seen bug #374002
(In reply to comment #645) > Is somebody maintaining seamonkey|firefox forks with MNG support and with > binary packages readily downloadable? http://sourceforge.net/project/showfiles.php?group_id=92539
I must confess, it's very disappointing to see this kind of response (closed/wontfix) to a report that is obviously very highly desired. I dare say it's even heavy handed to assume to know better than voters what is and isn't important to them. No, this isn't a democracy, but still..
This bug is a shame; the arrogance in developer comments is a disgrace; and marking it "resolved" is ridiculous. As a previous commenter duly noted, this stupidity managed to kill MNG and help flash to the position it is today. Wake up folks, these are your users here, we're the people who make websites and we know better than you what features we need!
(In reply to comment #649) > This bug is a shame; the arrogance in developer comments is a disgrace; and > marking it "resolved" is ridiculous. As a previous commenter duly noted, this > stupidity managed to kill MNG and help flash to the position it is today. Wake > up folks, these are your users here, we're the people who make websites and we > know better than you what features we need! > Wake up guys. You shouldn't be comparing Flash/Shockwave with MNG as the former can do much much more than MNG, which has no audio, no interactivity, etc. Flash/Shockwave and MNG are 2 categories of files. You should only compare MNG with images of the same type, e.g. GIF, APNG. Putting negative commments doesn't help in any way. So please stop bug spamming and do something else useful.
OK, so we have APNG which provides animated lossless images. What about animated lossy images though? Should a separate bug be filed for JNG (lossy with alpha)? Should a new format AJNG be made to allow animated lossy images? If that bug is wontfix, please tell me which bugs I should support for those two issues that need to be addressed in the web of today. Simply merging everything with MNG seems simpler to me though. And it will need less code. MNG also has some support elsewhere unlike APNG and the yet to be created AJNG.
(In reply to comment #650) > Wake up guys. You shouldn't be comparing Flash/Shockwave with MNG as the former > can do much much more than MNG, which has no audio, no interactivity, etc. > Flash/Shockwave and MNG are 2 categories of files. You should only compare MNG > with images of the same type, e.g. GIF, APNG. Excuse me. MNG -DOES- have interactivity. You also don't need a degree in computer science to make an MNG, unlike Flash.
This bug is WONTFIX not because of any personal bias or arrogance, but because there is no desire to ship MNG in Firefox in the future. It shipped in Mozilla 1.0 through 1.3, and Netscape 7.0, and had trivial usage on the web, and was backed out before Mozilla 1.4 and Firebird 0.6.1. There were a small number of MNG images on the web (less than the number of votes on this bug) most posted as examples of the tech, rather than actually being used. Drivers considered and reconsidered MNG, staff considered it, and the decision stuck. There was an allowance made for bringing it back in CVS subject to finding an appropriate owner, but no committment was made to ship it even in that case. It wasn't the right answer, or even answering the right question, to sum up the opinions. Ultimately, we have been successful as a project by ensuring that we have strong technical and product leadership, and making the right decisions, whether those decisions are popular or violently opposed. This is one of those decisions that will be controversial, not the first or the last, to be sure. I understand that people who are on the wrong side of such a decision will feel slighted or even rejected, but I would strongly encourage people to give others the benefit of the doubt and believe that decisions are being made in the best interests of the future of the web and of end users.
Status: RESOLVED → VERIFIED
I don't know Mike. Your sentiment has all the calming reassurances one would expect from an impartial mediator, but completely lacks any concrete set of facts, details, timelines, or even summary of why MNG is not supported by Firefox. What we DO know is that the one-and-only true opponent is the owner of imglib, who gave seemingly impossible and arbitrary goals for mnglib to fulfill, which it did, and turned out to be not good enough. No further explaination given. What we DO know is that same imglib had also succomb to the recent PNG exploit which made Firefox look bad, while mnglib had no such affliction. It is most unfortunate that Sir Pavlov refused to adopt mnglib, allowing us to ride out the exploit laughing all the way. For that reason alone, I believe he should be relinquished of his post. So what that Firebird 0.6 supported MNG, and MNG had less use than the votes in this poll. Firebird had less USERS than the votes in this poll. Even Shockwave Flash sites were fewer than the votes in this poll! Really, 820 is a pretty large number of multi-media sites for 2003, and broadband was only on the verge of becoming available/affordable. Also, MNG support only lasted for 28~30 months yet attracted this much attention and vested interest. See also comment #78 and bug 163993, and compare to bug 195280. Until someone can explain why this bug was officially sanctioned as a to-do/not-do bug, requiring only 50 votes (and got over 800), and while 195280 won with only 2 votes (!!)... you will ALWAYS have conspiracy theorists abound-- myself included.
mng can be compared to flash, because many simpler flash uses could be replaced by mng... check the ad banners for example... java cant be compared to flash, but they have a grey area were both can be used. with mng you have the same idea.
just to mention it: MNG isn't the only image format which support has been rejected for no proper reason. there are also other great image technologies which could be very beneficial in the web. for example there was a "decision" going on in bugzilla about the jpeg2k format which is the improved and newer version of the wide spreaded .jpg image files. .jp2 files can be smaller at better quality. you can even save images lossless. the support request was delined. there was also no proper reason given. https://bugzilla.mozilla.org/show_bug.cgi?id=36351 So the question if mozilla should support the MNG format is actually more a question if there should be done any improvements in the imglib. In my eyes the imglib is totally out of date. have a look at a few formats which are beeing supported: - there is the gif format, which has been introduced 20 years ago (1987) - there is the jpg format, which has been introduced 15 years ago (1992) - and hey, we also got something really modern, it's the png format, which will celebrate it's 11th birthday in october! If the newest part of my computer was 11 years old it would be barely worth it's name.
(In reply to comment #656) > just to mention it: MNG isn't the only image format which support has been > rejected for no proper reason. there are also other great image technologies > which could be very beneficial in the web. > > for example there was a "decision" going on in bugzilla about the jpeg2k format > which is the improved and newer version of the wide spreaded .jpg image files. > .jp2 files can be smaller at better quality. you can even save images lossless. > the support request was delined. there was also no proper reason given. > > https://bugzilla.mozilla.org/show_bug.cgi?id=36351 Bug 36351 is not "declined". Its status is still "NEW". > So the question if mozilla should support the MNG format is actually more a > question if there should be done any improvements in the imglib. Then file a separate bug instead of bug spamming here. Make sure you search before reporting: https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&content=imglib
(In reply to comment #654) > See also comment #78 and bug 163993, and compare to bug 195280. Until someone > can explain why this bug was officially sanctioned as a to-do/not-do bug, > requiring only 50 votes (and got over 800), and while 195280 won with only 2 > votes (!!)... you will ALWAYS have conspiracy theorists abound-- myself > included. Funny you should mention conspiracies... This bug and all the hoopla surrounding it somehow came up in conversation with a relative who's never used mozilla before (he uses Safari on a Mac), and his immediate reaction was that someone must be on the take. I don't quite share that view; it just looks like stubbornness and pride to me. An unwillingness to revisit a prior decision that may have been made for the wrong reasons or under circumstances that have since changed. I've been subscribed to this bug for all these years and still hope to see mng readded. Back then, the reason was that the library was selected to be cut in an effort to pare back mozilla's download size. The fact that it wasn't used much was considered minor, as presumably reasonable folk understood that it was a chicken-and-egg problem. It later became an issue of a lack of maintainer, but it didn't take long before mnglib received maintenance and was even refined to be lean and mean. Even then it still didn't receive support, but they were seemingly out of excuses and began resorting to nebulous explanations that fail to adequately justify the position, much like those showing up again today. Funny that lack of mng adoption is now the focus and the reasons for this completely ignored. Mng is a solid technology, and the library has become very robust. Since I run a source-based distro, I had resorted to incorporating the mng patches that cropped up whenever I built a new version. There have been several image vulnerabilities over the years that I've been unaffacted by due to using mnglib in place for handling. (In reply to comment #653) > This bug is WONTFIX not because of any personal bias or arrogance Mike, I read and understand what you're saying but it's quite simply impossible for me to believe this given how I've seen this whole issue progress. They had the benefit of the doubt at one point, but it has long since expired.
What Target said. The "benefit of doubt" was to keep subscribed to this bug for years, instead of starting right away to tell people to use iceweasel or konqueror or something else because mozilla/firefox is clearly headless.
(In reply to comment #659) > What Target said. The "benefit of doubt" was to keep subscribed to this bug > for years, instead of starting right away to tell people to use iceweasel or > konqueror or something else because mozilla/firefox is clearly headless. > How right is this... I don't agree with the decision taken or how it has been handled all those years and now. However, to all those that keep complaining about that, even though Mozilla has said the last word a long long time ago and again now. What have you done in 7+ years? If you are so **** off, why haven't you switched and promoted another browser that supports MNG? Have you produced and romoted MNG content thus creating an interest? Furthermore, this is free software! If it were not, the issue would have been over already. However, individuals and distributions have the right (and they do exercise that right) to modify the code and ship modified versions. Have you provided patches to distributions so they distribute Mozilla+MNG ? Have you advocated those patches? Look what Debian did. They had an issue with Mozilla Corp., so they bit the bullet, took the burden upon themselves and they are going to ship Iceweasel. And in much less than 7+ years and with less than 800 people to support it. That is how things get done. Not whinning in a remote corner of Mozilla's bugzilla.
It occurs to me that this bug was closed preemptively to bolster momentum towards APNG ratification. This bug should remain open at least until APNG is a finalised, independent specification, if it is accepted as such. Until that point there is simply no basis for comparison.
As a long time follower of this bug, I would like to weight in as well. It has been obvious for a while that this issue will not be fixed in the official Mozilla tree as it is. The developers have made it quite clear even if the reasons do not satisfy all the voters. The solution at this point is not to force this issue on the Mozilla developers or to switch to completely different browser if other Firefox features satisfy the user. The correct solution, in my opinion, is to start using and making available a fork that implements mng/jng and perhaps other image formats that are needed by the community but not implemented by the official tree. Fork should follow the official development tree in all the other issues that Mozilla developers have time and interest to keep updated. Developers of the forked version can then concentrate on having the missing functionality implemented and to keep their branch updated with official tree. This way the strength of open source development is used the best way. There does not need to be that much controversy over this issue. Mozilla developers can be happy with their decision by knowing that not all of their users are moving to use that fork. Users and developers of the forked version can be happy with the properties of their browser. When that fork is made available to larger crowd of people, Firefox will lose some of the users and forked version will gain them. If there are no breakage introduced by merging mng code, there will be little switching back as long as tree is kept updated. It just needs some marketing and mind share after that. I'm quite sure that this has been the problem for many web developers: Because there's no mng support in browsers, web developers can't use mng technology in their services even if they wanted to. I would recommend them to start using it anyway (perhaps using alternative methods to other browsers to gain popularity for the service) as there are already some browsers that support it. The only reason to switch to (or to try) mng-enabled browser will be a web service (or some local requirement) that is much better with that support. The user should not lose anything as the software is basically Firefox anyway. It only has some cool extra features. In any case, mng support will be available to those that need it and will make it possible to offer mng based services for growing number of users that have mng-enabled browsers. Only time will tell if there's still enough need to that format in the web. At some later date, Mozilla developers can review the issue (if they feel like it) of merging any missing features that they want to offer to their current users. As mng patches already exist, the issue of making a deliverable product for end users should not be that difficult. Making mng-using services and educating people about new choice will be harder. In any case, as the software is not inferior in any way, converting users is not impossible. If both download links are offered next to each others, I'm quite sure that people will choose the one with mng support even if the file size written next to download link seems to be some kilobytes larger.
I don't think users would switch over too much, though. Here's an alternative take: could this be done in a plugin? Flash is a plugin, after all. And then, the plugin would be automatically offered for installation when someone looks at a page that has MNG. I realise of course it would be slower than the version implemented by the patch, which replaces imglib; but it would probably be the best way to "raise awareness" and create an user base. From my understanding, the greater non-technical reason why this plug-in isn't yet in wide use is that this bug was already open, so we 814 fools were still hoping. Ok, now we know it "WONTFIX", so let's start advertising the plugin instead. How does that sound?
sounds OK, except that right now the current plugin available doesn't render transparencies properly, if it's a fixable problem, that needs to happen first
I think there are very simple steps that could be achieved in order to get to a better situation than that of today, and that may not be refused by Mozilla, and could even help adding other image formats, such as jpeg2000 (see bug #36351) The overall goal of my proposal would be to make it more possible than it currently is to have "external" handlers for images (external as in put that in an separate xpi) Looking at the latest patch for mng support, here is what I see should be added to Mozilla that would help everyone and make a good external mng support (even for those served as text/plain) for mozilla: - Add hooks for image content sniffing. Like allowing components to register something like @mozilla.org/content/image-sniffer?type=$type that would be used whenever imgLoader::GetMimeTypeFromContent doesn't find the hard coded types. - Allow the Accept request header for images to be customized, as it is possible for normal HTTP requests with network.http.accept_default. These are the 2 only changes I can see in the current mng patch that make the support require to be "statically" built in Mozilla. If it was made easier for image handlers to be made out-tree, it would be good for everyone.
It has been mentioned in the evergrowing comment list of this bug that this can even be done as a Firefox extension. There is still a small glitch that makes that approach not ideal yet, I think with aceppt HTTP header or content sniffing or such, but from what I heard, it should be possible to do a patch and get it into the main Mozilla/Firefox tree if someone is really willing to work on that. Fixing the small existing issues ther would make it possible to add any image format you want just as a "simple" Firefox extension (or SeaMonkey extension, Mozilla Platform extension, or whatever you call it then). The MNG working group tried to solve too much at once with their format, this is why the spec itself is disliked by many people (just like SVG 1.2, BTW) - and this is probably the main reason why people don't want to see native support in their image library for this. Anyways, if anyone can install it as an extension, everyone should be happy. And if that extension is downloaded by really really many people, who knows, even module owners could revisit that topic. Please, just accept that MNG has no chance of getting into the main mozilla.org build tree or official builds as long as the current spec and current adoption of the format stay where they are. Comment #634 is a good read for that. There is a need for a true-color, alpha-supporting raster animation format, but MNG tries to solve a lot more that that and shoots over the target, and will not re-enter the main Mozilla codebase. If you want it, good. An extension is the way to go. I'm sure imglib people will be happy to review improvements to their support for plugging in image formats as extensions. Pleas do that work in different bugs though, this one here is more or less unreadable due to its 666 comment to date (a good number to stop it, BTW).
(In reply to comment #653) > This bug is WONTFIX not because of any personal bias or arrogance, but because > there is no desire to ship MNG in Firefox in the future. I've been on the CC list and vote list for this bug for years, simply because MNG support sounded like a good idea on general principle, and a natural companion to PNG, but I have no personal stake in the matter. This is my first post to this bug. I'm not a web developer hoping to produce MNG content in the future. Although I'm a programmer, my interest in this bug is solely as an end user and supporter of open source software. As such, I consider myself a fairly neutral observer -- I have no vested interested here, although I have remained vaguely aware of this bug over the years. I'd like to make several observations. Although I've heard wonderful things about Stuart's contributions before, and I don't want my comments to be interpreted as a personal attack against him, I can nevertheless understand how accusations of personal bias and arrogance against Stuart could arise in the context of this bug. For example, way back in 2003, in comment #273, Stuart said "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." This was a perfectly reasonable statement, and set a goal and expectation for those who wanted MNG support in Mozilla. However, cut to 2005, and Stuart is complaining in comment #600 about "putting new patches in this bug every few days". Hmm, that sounds like MNG must have found that missing maintainer (someone is making those patches and keeping them up to date) -- why would it be a problem that someone keeps making up-to-date patches for MNG support? I thought the whole idea was to give someone like that CVS commit privileges and ownership of that part of the code, not to complain about the effort and try to get them to go away! Finally, Stuart weighs in yesterday in comment #622 with a flat "We aren't going to add back MNG support." Nowhere in the history of this bug do I see any clear explanation from Stuart (who obviously has the controlling opinion) for this change of heart about MNG support in Mozilla. He seemed to be open to the idea of MNG support in 2003 if someone who cared enough about it would put the work into making it happen. Now, it's quite clear that his mind is closed, but it's not clear why his attitude shifted from "we need a volunteer" to "over my dead body". I'm sure Stuart must be annoyed with the extreme provocation I've seen in other comments in this bug over the years -- and I'm not excusing such behavior. Even so, it's not unreasonable for the hundreds of interested observers (most of whom have not even been posting to this bug) to expect a clear, reasonable explanation from the module owner as to why such a popular request has been flatly rejected. There may be perfectly good reasons, but Stuart has never explained his decision (at least in these comments), while it does appear that others HAVE addressed the earlier objections from years ago. That makes his current refusal to consider MNG seem all the more inexplicable and arbitrary. As for the accusation of arrogance, perhaps Stuart isn't arrogant by nature and I know there's been plenty of provocation in the comments on this bug, but Stuart's dismissive "your vote doesn't matter" remark in comment #624 does come across as arrogant, even if it that may seem out of character to people who know Stuart personally. Similarly, the comment that "I'm the module owner and we've been over this. People tried to go over my head and got shot down." Again, this comes across as arrogant -- he's the module owner, so his opinion is the only one that matters, and he need not explain himself -- and also suggests some level of personal animosity toward MNG (or at least certain supporters of MNG) for disrepecting his role as module owner. Personally, I doubt that Stuart is actually arrogant; I've heard of him before, and I certainly had never gotten that impression. However, taking some of his comments from this bug in isolation, I can see how people might accuse him of arrogance with respect to MNG. > Drivers considered and reconsidered MNG, staff considered it, and the decision > stuck. There was an allowance made for bringing it back in CVS subject to > finding an appropriate owner, but no committment was made to ship it even in > that case. It wasn't the right answer, or even answering the right question, > to sum up the opinions. Perhaps it would help to define what the right question is, hopefully taking the opinions of the web developers into account. Clearly, there is a great desire for some sort of animated image format, whether or not MNG is the right answer. We seem to have two polarized sides in an argument over MNG support. Clearly, this isn't good for either side in the end -- instead of having both sides dig in further, or split ways and create a fork, how about trying to set aside the animosity and hurt feelings and just try to get on the same page about what everyone really needs and wants here? It appears that most of the MNG supporters are interested in their functional needs and widespread deployment, rather than being personally invested in MNG in particular. Rather than continuing to argue over the current situation and how we got here, how about putting this bug spam to good use by transforming it into a constructive debate about the actual needs and requirements of the web developers, and the constraints that Stuart and the Mozilla drivers consider necessary for inclusion in the mainline Mozilla/Firefox builds by default? (That should be the target, after all: an animated image format that can become as ubiquitous as JPEG already is -- or most web developers won't use it.) The people involved with this bug seem to have plenty of interest, knowledge and motivation to go around -- if necessary, develop a new image format and new code from scratch to meet the actual needs. That's how PNG came into existence; perhaps that process is justified here, if MNG isn't appropriate. After all, this bug has been open for 7 years -- PNG was widespread and stable in less time than that! > Ultimately, we have been successful as a project by ensuring that we have > strong technical and product leadership, and making the right decisions, > whether those decisions are popular or violently opposed. While that may be true on the whole, with respect to this bug, there seems to have been a lack of leadership. There's clearly an unmet need that's causing so many people to continue agitating for MNG, year after year. True leadership would have seen that need met somehow, whether or not MNG was used to meet it, and this controversy would have been moot by now. I don't think the angst displayed in the comments here originates from the fact that a decision was made that people disagree with, but rather the process by which that decision was made, the lack of transparency in that process, the general attitude displayed by those in power, and the clear neglect of the unmet need that has kept so many people interested in this bug for so many years.
Before a technology can be used on the web, browsers must support it first. Making an a priori judgment that MNG has technical problems that will cause it to never be adopted, and offering this reasoning as an excuse for why Mozilla should not support MNG, is a self-fulfilling prophecy at best. I realize Mozilla did support MNG for some time years ago, but that was when it had around 1% share. MNG support was removed before Mozilla and MNG could catch on, and perhaps that is the main reason that MNG is not used today. If Mozilla waits until technology is used before Mozilla supports it, Mozilla will support only what Microsoft chooses to support in Internet Explorer. For those of you suggesting that plugins can be used to support MNG, you're missing this point. Many people want MNG supported so they can use it on their web sites. They generally aren't going to use it if they need to tell their users to download and install a little-known plugin just to view the content on their site. For MNG (or any other web technology) to be usable, it must be available to some significant fraction of visitors to a site without downloading, installing, or configuring anything. For the record, I really don't care about MNG. However, I do care that invalid reasoning is being used to justify technical decisions, and that the Mozilla Manifesto principle of using "transparent community-based processes" is clearly not being followed. No, this is not a democracy, but being suddenly handed down a decree that MNG will not be supported, without any reasonable justification, is far from what the Manifesto seems to describe. Lastly, could we please move this discussion somewhere else?
Has anyone done a recent comparison of code size delta (including compressing the miniscule Firefox throbber and replacing libpng with libmng) on the latest FF3 source? The last comparison I can find was in this bug, done in 2003.
(In reply to comment #660) > How right is this... > > I don't agree with the decision taken or how it has been handled all those > years and now. However, to all those that keep complaining about that, even > though Mozilla has said the last word a long long time ago and again now. What > have you done in 7+ years? If you are so **** off, why haven't you switched > and promoted another browser that supports MNG? Have you produced and romoted > MNG content thus creating an interest? > Most of us aren't (C, C++, whatever) programmers and have no idea about how the Mozilla source works -- if we had, there would have been a maintainer for the lib ages ago and we wouldn't be "spamming" this bug ever since. As an aside, I seem to remember that just before Stuart "I'm all for removing this" Parmenter took out the support, someone offered to maintain and Glenn was working really hard to reduce the footprint of the mng code as much as possible (never mind that since then, Firefox has become the biggest memory hog in the Milky Way due to other "features" that have been untreated in the last year and more...). Highly recommended read: https://bugzilla.mozilla.org/show_bug.cgi?id=195280 comments arount 20 and above. Some of hixie's and dbaron's comments are really good and insightful. Other browsers are not prominent enough (hello 10%+ market share of Mozilla products!), not available on all platforms (Konqueror), or have other issues. > Furthermore, this is free software! If it were not, the issue would have been > over already. However, individuals and distributions have the right (and they > do exercise that right) to modify the code and ship modified versions. Have you > provided patches to distributions so they distribute Mozilla+MNG ? Have you > advocated those patches? > See above. If anything, the way this was handled just reminds me of the native rendering issue around the Windows version of Firefox, and that they changed the default skin to look like ass on Classic, which apparently quite a lot of people use. How Silver was treated when he was working **** the patches to get around the issues with the look&feel, faced by a brick wall, just like Gerv, Gerard and Glenn here. Same damn thing, and it makes me feel very bad about people in power here. So... yeah. Sucks. Makes me glad I'm using Konqueror now most of the time.
I filed bugs #374088 and #374089 to implement what I proposed in comment #665.
Depends on: 374088, 374089
Rather than everyone complain in here, why is MNGzilla not on http://addons.mozilla.org? Imagelib is extensible. There is no need for "forks" or anything else to add new image formats. You can install them just like any other extension. I've suggested to at least 3 people in the last week or two that time would be much better spent adding support for an image type finder similar to the plugin finder and making sure that your image formats are up on amo so that people can actually find them! Anyways, here is a post I made to the png list about MNG a while ago that never ended up here. I think it echos most of my feelings about this issue pretty well. > ---------- Forwarded message ---------- > From: Stuart Parmenter > Date: Sep 5, 2004 3:46 PM > Subject: Re: [png-list] Questioning an assumption > To: png-list@ccrc.wustl.edu > > > On Sun, 5 Sep 2004 09:28:48 -0700 (PDT), Thomas Boutell >> Even though I'm inclined to favor APNG, this question ought to be asked, >> and it hasn't been asked in the context of this discussion: >> >> What's keeping MNG from being used to serve the specific purpose the Mozilla >> team had in mind here? Animations for themes, right? > > Theme developers have definitely asked for animated PNG files so they > can have nice antialiased borders around the curves in their images. > > In addition to general use on the web, there is also a large class of > web applications who would benefit from this. Backwards compatibility > is key for using images on the web. > >> My understanding is that libmng was too big, partly because of redundant >> libpng implementations, so it got punted from Mozilla as part of the >> general drive to make Mozilla less of a pig. Which, of course, Mozilla >> was, and Mozilla/Firefox *is* more lightweight now. >> >> But then libmng shrank... and it still didn't go back in. >> >> So... what's the story there? I think it's a legitimate question for >> Vladimir, Stuart, and anyone else familiar with the MNG-in-Mozilla >> situation. > > Looking back at the whole MNG issue, I really wish that I never said > it was OK to add MNG support. We should have pushed back that MNG was > too complex and too big before ever adding support for it. We drank a > bit too much of the "animated PNGs would be nice" kool-aid and ignored > a lot of factors that we later realized. > > Some of the questions we should have asked ourselves before including > MNG support include: > What is MNG trying to solve? If it is trying to be Flash, it probably > isn't what we want. > What do the MNG profiles mean to us? If editors only spit out full > MNG images, then browsers forced to support the full MNG profile in > order to display them? If they only support VLC, then why do the > other profiles exist? > Why is libmng not built on top of libpng? Do we really need another > PNG decoder? Even if we could use it to decode PNGs, are we willing > to switch to a much less mature library with no real security track > record? What kind of performance would it have compared to libpng? > Are people going to actually use MNGs on the web or are we adding this > just for the UI? If they are just for the UI, we can probably come up > with a much more simple way of doing them. > Do we have someone willing to work on the Mozilla decoder part? > Someone responsible for fixing the bugs in the code connecting Mozilla > and libmng? > > I think we made the assumption that because it was based on PNG, which > is a nice simple format, that MNG would also be. Boy were we wrong. > If we had looked at these things first, I don't think MNG ever would > have made it in to Mozilla. I take full responsibility for not doing > my homework here. > > If we had looked at these things, we would have seen that MNG was > trying to be a fully interactive video/animation format with dreams of > competing with Flash. We would have seen that MNG profiles didn't > make sense and that the only thing we could really support would be > the full MNG profile. We would have seen that we didn't want to use > libmng for decoding PNGs and that what we would want in a MNG decoder > is for it to be built on top of libpng. We really don't need 2 PNG > decoders in Mozilla. I believe we would have seen that people would > want to use MNGs in the chrome only as a GIF replacement and that no > one would really start adding MNGs on the web probably due to IE not > supporting them. MNG doesn't provide a graceful fallback in > non-supporting browsers and as Ian pointed out using <object> isn't a > good alternative. > > If we take a look at the numbers around the time MNG was removed, we > had a 115kb libpng and around a 350kb libmng. We didn't have anyone > who wanted to fix the bugs in the Mozilla MNG glue code and we hadn't > seen any growth in MNGs on the web in the 2 years that we had > supported MNG. > > There has been a lot of great work that has gone in to shrinking both > libmng and libpng in the last year since it was removed. The size of > libpng in Mozilla has been cut in half and libmng has been cut down a > lot. You ask why when it was shrunk it wasn't added back. If we > took every new 100k addon we'd be back to the size we used to be at. > Does finding savings in one place mean that we should add something > new to take up that space again? Most importantly, it was never > simply about size. Had MNG (the whole format -- profiles just don't > work) been a simple animated PNG solution it may have been the right > fit for us, but alas. We don't need 2 PNG decoders, and we don't want > to use libmng for decoding PNGs. There are still a number of > MNG-Mozilla glue bugs including various crashers. > > I really wish that animation had made it in to the original PNG spec. > If it had, I think it would have looked a lot like APNG (Although > probably with support for more critical chunks, require order to be > kept, etc). There are some things that MNG can do that are useful and > for that I see no reason why people can't install an extension to add > MNG support to their browser (at least in Mozilla, since image > decoders are pluggable). There is talk of making unknown images > support finding extensions to display them just like plugins do now. > > I think we learned a lot when we removed it. Users really love adding > new features but get really upset if you even think about removing > some. In a way, I was sad to be removing it since having animated > PNGs _is_ a good thing, but I'm not sure MNG was the right solution. > I stand by my decision to remove MNG. My only regret is that I let it > go in in the first place. > > At this point, Mozilla is planning on fully supporting APNG. I > suspect other browser vendors will follow... For what the web seems > to use, I just don't see a need for both APNG and MNG in Mozilla. > Firefox has made installing extensions very simple and I hope to see a > MNG extension on updates.mozilla.org for Firefox 1.0. Those wanting > to install it should feel free to do so. > > I hope this clears things up. > > stuart
Stuart, thanks for copying that post into these comments -- I think most of us have no idea what is happening behind the scenes, so we had no idea that you had explained your position so carefully. Hopefully this will dispel the notion that your refusal to re-add MNG support is arrogant, arbitrary or the result of a personal bias. As for supporting MNG as an extension/plugin, can it be automatically downloaded as soon as it's needed, then work as well as it did as fully-integrated code? Requiring users to take steps to add support for a new format will tend to prevent its adoption, but having the additional code be downloaded on demand is quite reasonable, and already standard practice for codecs in media players...
Quote: "There is talk of making unknown images support finding extensions to display them just like plugins do now." I think that answers your question.
(In reply to comment #674) > Quote: "There is talk of making unknown images support finding extensions to > display them just like plugins do now." > > I think that answers your question. I didn't miss that remark, I was hoping to focus the debate on something useful. But will it actually work as well as the integrated code? See comment #664: > sounds OK, except that right now the current plugin available doesn't render > transparencies properly, if it's a fixable problem, that needs to happen first If there are indeed any issues or loss of functionality caused by moving from integrated code to an extension, that obviously should be fixed, but a new bug would be appropriate, not resolving such issues in the context of this bug. Assuming the extension is 100% functional, the only remaining arguments for MNG inclusion in the core would be ubiquity (GIF and JPEG qualify, MNG currently does not) or to lower the barrier for users to view MNG images. I think the latter argument is what the web developers are agitating for, so they can use MNG and be confident that anyone using Firefox can view the images. If that's the real need at this point, then Stuart is clearly right -- the focus should be on making the installation of the MNG extension completely automatic and transparent, not reintegrating MNG into the core. That way, ALL image formats can benefit instead of just one. Users are willing to download plugins and codecs when they're first needed; why should an image decoder be different? What is the bug number for automatically and transparently finding, downloading and installing image decoder extensions? That's what we should be focused on.
My ideas: 1. Even if we don't support it in official builds, MNG should be in the source tree. It would be good not to have to apply a patch to your tree just to build Mozilla with MNG. 2. For the plugin/extension issue: Currently, we have 2 optional components i the installer: Inspector and Crash Reporter. Why not add "MNG Decoder" to the list? Maybe it shouldn't be in the installer, but instead it should be downloaded automatically by the installer if it is selected. Also, I don't see a point why we are against using LibMNG for PNG decoding. Just because that PNG is older and more proven, that is conservativism, something that isn't good in computertechnics. Also, APNG isn't really acceptable, since it is not a final standard. Implementing a standard aged a few years old is much more worth than implementing a workdraft! Currently, we are left with GIF if we want to convey animations to users of platforms not supported by Adobe! (And even in that case, Flash can't really be recommended, as there is no free Flash authoring tool!) So, it's definitely MNG what we want.
(In reply to comment #672) > > At this point, Mozilla is planning on fully supporting APNG. I > > suspect other browser vendors will follow... For what the web seems > > to use, I just don't see a need for both APNG and MNG in Mozilla. > > Firefox has made installing extensions very simple and I hope to see a > > MNG extension on updates.mozilla.org for Firefox 1.0. Those wanting > > to install it should feel free to do so. All right, no MNG because we're doing APNG instead. Fine. Uh, where's APNG? That message was from 2004, before Firefox 1.0. We're past 2.0 now and I don't see any APNG support. I don't even see it in the planning documents for 3.0. The spec hasn't even hit 1.0 yet. How many more years is it going to take before APNG is ready? MNG has a stable library, tool support, and a finished patch *right now*. Obviously MNG's never going to get in at this point, and maybe it doesn't deserve to get in, but the "APNG is better" argument is cold comfort to web developers when for all practical purposes APNG doesn't even exist.
Forget about getting MNG back into the core. It's obviously not happening. Forget about APNG support. It's a red herring. Focus on the problem of making the MNG extension work perfectly, having it readily available on "addons.mozilla.org" (for as many platforms as possible) and have it be installed without user effort when any Firefox user tries to use an image with either "image/x-mng" or "video/x-mng" as the MIME type, or ".mng" as the extension. In other words, worry about the hypothetical "image decoder finder" that Stuart suggested. That's the best solution to this controversy. Get all this to work transparently, and everyone can be happy. MNG will then be readily available to any Firefox users (with a new enough version of Firefox), but it won't bloat the core code or the initial download. The user will have to wait for a download (and should probably confirm that they want it), but only once and when it's actually needed. It won't waste space if it's not needed, and it won't be any more of a burden on the user to install than a missing codec in a media player that's automatically downloaded on demand. What won't work is to require the user to manually seek out and install the extension, especially if it requires manual configuration. Most users won't do that. Forking the distribution won't work without getting similar mindshare and market share, and that's a near-impossible task. Reintegrating the MNG code into the core would work for the web developers, but it's time to stop tilting at that windmill and solve the real problem -- users need to be able to use MNG without effort, so web developers can use it. Once that problem is solved, there's no value in having MNG in the core.
(In reply to comment #647) > (In reply to comment #645) > > Is somebody maintaining seamonkey|firefox forks with MNG support and with > > binary packages readily downloadable? > > http://sourceforge.net/project/showfiles.php?group_id=92539 You must be kidding! Browser packages published somewhere between spring 2005 and spring 2006 don't count in spring 2007.
(In reply to comment #653) > understand that people who are on the wrong side of such a decision will feel > slighted or even rejected, but I would strongly encourage people to give others > the benefit of the doubt and believe that decisions are being made in the best > interests of the future of the web and of end users. FWIW, I lost this kind of trust in the Mozilla Foundation at the latest when they slashed the suite, shortly before 1.8. Planting web bugs in FF, as has also happened, together with this very twisted reasoning about the MNG problem (others have cleared that up nicely, thank you, Raccoon) does nothing to restore such kind of trust. I'm not going so far as to assume a hidden agenda yet, but most of your arguments in this discussion are _very_ fishy from where I stand.
(In reply to comment #672) While I appreciate this post i don't think all the reasons are valid or up to date. > >> What's keeping MNG from being used to serve the specific purpose the Mozilla > >> team had in mind here? Animations for themes, right? > > > >> My understanding is that libmng was too big, partly because of redundant > >> libpng implementations, so it got punted from Mozilla as part of the > >> general drive to make Mozilla less of a pig. Which, of course, Mozilla > >> was, and Mozilla/Firefox *is* more lightweight now. > >> > >> But then libmng shrank... and it still didn't go back in. Thats right from what I can see in this thread. The original package was stated to be to big and so it was worked on to get the size down. But still did'nt get back in. > > Looking back at the whole MNG issue, I really wish that I never said > > it was OK to add MNG support. We should have pushed back that MNG was > > too complex and too big before ever adding support for it. We drank a > > bit too much of the "animated PNGs would be nice" kool-aid and ignored > > a lot of factors that we later realized. > > > > Some of the questions we should have asked ourselves before including > > MNG support include: > > What is MNG trying to solve? If it is trying to be Flash, it probably > > isn't what we want. Ok the MNG spec is quiet big and encompasses some flash aspects. But the idea of the of MNG is not to be flash and never was. I don't know why people keep making this comparison. Besides as one of the resent posts mentions how many 64bit environment and none windows OS's have flash? Next to none as its a closed source proprietary annoying format. MNG is open and will provide feature the community is requesting hence why this thread is so keenly watched. > > What do the MNG profiles mean to us? If editors only spit out full > > MNG images, then browsers forced to support the full MNG profile in > > order to display them? If they only support VLC, then why do the > > other profiles exist? I was under the impression that the profiles were created as a way of taking some features out of MNG as an effort to save space since the reason provided to the maintainer was that it was to big. However all along people have been stating they would prefer the full MNG profile as apposed to having it cut down. > > Why is libmng not built on top of libpng? Do we really need another > > PNG decoder? Even if we could use it to decode PNGs, are we willing > > to switch to a much less mature library with no real security track > > record? I can't answer why it is not built on PNG this could be one for the maintainer. But does it really matter. From what posts have been made MNG has its own PNG decoder and will not as mature is pretty dam good. Just take out the old PNG decoder and put MNG in which will give you PNG anyway. There no need to duplicate as the maintainer has already mentioned previously. What kind of performance would it have compared to libpng? > > Are people going to actually use MNGs on the web or are we adding this > > just for the UI? If they are just for the UI, we can probably come up > > with a much more simple way of doing them. > > Do we have someone willing to work on the Mozilla decoder part? > > Someone responsible for fixing the bugs in the code connecting Mozilla > > and libmng? With the number of people watching this thread I think people are keen to use it on there websites. But without support for it why would they bother. > > If we had looked at these things, we would have seen that MNG was > > trying to be a fully interactive video/animation format with dreams of > > competing with Flash. Did'nt we already cover this. MNG is not flash. And even if it was would that be such a bad thing. At least it would work on all platforms unlike flash. >> We would have seen that MNG profiles didn't > > make sense and that the only thing we could really support would be > > the full MNG profile. Thats right the profile were made to try and bring size down in the hope that if the full MNG support was to big perhaps the core components could just make it back in. We would have seen that we didn't want to use > > libmng for decoding PNGs and that what we would want in a MNG decoder > > is for it to be built on top of libpng. We really don't need 2 PNG > > decoders in Mozilla. I believe we would have seen that people would > > want to use MNGs in the chrome only as a GIF replacement and that no > > one would really start adding MNGs on the web probably due to IE not > > supporting them. AS earlier there is no need to have two PNG decoders. Put MNG in and remove PNG, simple. I'm not to sure why he wants a MNG library based on libpng. Perhaps if the reasons were given I would understand better. In relation to the IE support comment. Last time I dabbled with MNG back when I voted for this bug(a long time ago now) IE had pretty good if not perfect support once the plug in was installed. > > MNG doesn't provide a graceful fallback in > > non-supporting browsers and as Ian pointed out using <object> isn't a > > good alternative. > > This should be more of a separate bug shouldn't it. Its hardly MNGs fault the browser does not provide a graceful fallback > > There has been a lot of great work that has gone in to shrinking both > > libmng and libpng in the last year since it was removed. The size of > > libpng in Mozilla has been cut in half and libmng has been cut down a > > lot. You ask why when it was shrunk it wasn't added back. If we > > took every new 100k addon we'd be back to the size we used to be at. > > Does finding savings in one place mean that we should add something > > new to take up that space again? Most importantly, it was never > > simply about size. Had MNG (the whole format -- profiles just don't > > work) been a simple animated PNG solution it may have been the right > > fit for us, but alas. We don't need 2 PNG decoders, and we don't want > > to use libmng for decoding PNGs. There are still a number of > > MNG-Mozilla glue bugs including various crashers. > > I really wish that animation had made it in to the original PNG spec. > > If it had, I think it would have looked a lot like APNG (Although > > probably with support for more critical chunks, require order to be > > kept, etc). There are some things that MNG can do that are useful and > > for that I see no reason why people can't install an extension to add > > MNG support to their browser (at least in Mozilla, since image > > decoders are pluggable). There is talk of making unknown images > > support finding extensions to display them just like plugins do now. > > At this point, Mozilla is planning on fully supporting APNG. I > > suspect other browser vendors will follow... For what the web seems > > to use, I just don't see a need for both APNG and MNG in Mozilla. > > Firefox has made installing extensions very simple. So the size is now fine. Its useful and should be an extension, according to this comment. Thing is it was established long ago that the Mozilla core plugin system does not have the hooks to support all simple interactive MNGs. Hence why people want it back in and not a plugin. The only reason I see here why its not in is because we don't want MNG to decode PNG images and we don't want to duplicate PNG? Whats the big issue here I don't follow. Whats wrong with MNG decoding PNGs and if there is something wrong then let just have duplicate PNG libs until its fixed I'm sure the size isn't to bad.
OK. I wholeheartedly agree with Deven in comment #675 : I think the "automatic plugin" is the way, as we all see that this issue won't be solved the way we voted for (restore MNG in core). Pro-MNG will be happy if user experience is good when coming across a MNG file (automatic installation and all features available). MNG-non-believers will be happy because FF won't carry any "slow and buggy MNG bloatware" Moreover, we'll have a clearer separation of responsabilities between Mozilla plugin architecture maintainance and independant plugin maintainance, and it opens the door for new file formats (who said transparent MPEG's ?) Finally, for all "conspiracy theory fans", this is the way proposed by Stuart, so no fear of veto again from him (hopefully :-)) So in my view, we should split the work in 3 tasks. I searched for bug reports but couldn't find them in bugzilla right now, but maybe I missed duplicates. Just tell me if it's the case. 1) Automatically find and install suitable decoder when <img> tag links to an URL with unknown mime-type (From comment #674) > Quote: "There is talk of making unknown images support finding extensions to > display them just like plugins do now." I saw it more as a plugin than as an extension, due to the "backend" nature of the decoder, but I may be wrong... 2) Make sure the plugin or extension can access the canvas as if it was built-in (From comment #664) > sounds OK, except that right now the current plugin available doesn't render > transparencies properly, if it's a fixable problem, that needs to happen first Transparency for sure is a requirement. Does "extension" give more power than "plugin" in that regard ? 3) Implement the MNG decoder as a plugin I guess that would be the simplest part, right ? I for one would immediately move my vote from this (dead) bug to the new ones ... Just my 2 cents
So, not to steer this discussion in another direction, but as this bug was both for the MNG animation format AND for the adjunct JNG image format, I have to ask: What does this mean for JNG? As a Web designer and developer, I have an huge desire to be able to use lossily compressed images that also have transparency -- much moreso, honestly, than any sort of animated PNG format. JNG fits this bill perfectly, and has a specification that seems like it would be rather trivial to implement. Even if MNG is supplanted with APNG there will still exist a need for a format like JNG. I don't have the experience to make this happen, but I wonder what you think, pavlov, about finding someone to implement JNG, and whether opening another bug to make this happen would be a worthwhile endeavour.
(In reply to comment #670) > not available on all platforms (Konqueror) Konqueror (and the whole KDE 4) will be available on all platforms. See: http://www.kdelibs.com/ http://dot.kde.org/1055852609/ http://dot.kde.org/1107786164/ http://dot.kde.org/1119953618/
(In reply to comment #683) > So, not to steer this discussion in another direction, but as this bug was both > for the MNG animation format AND for the adjunct JNG image format, I have to > ask: What does this mean for JNG? There's HD Photo. But JNG is vastly superior to HD Photo in terms of simplicity and in terms of compression of the alpha channel (This from reading the HD Photo spec and not from any actual testing). HD Photo may offer increased compression of the RGB channels and maybe increased decoding speed. HD Photo would offer an increased "attack surface" as well, which has been one of the arguments (maybe not presented here) against MNG.
(In reply to comment #685) > (In reply to comment #683) > > So, not to steer this discussion in another direction, but as this bug was both > > for the MNG animation format AND for the adjunct JNG image format, I have to > > ask: What does this mean for JNG? > > There's HD Photo. But JNG is vastly superior to HD Photo in terms of > simplicity > and in terms of compression of the alpha channel (This from reading the > HD Photo spec and not from any actual testing). HD Photo may offer increased > compression of the RGB channels and maybe increased decoding speed. HD > Photo would offer an increased "attack surface" as well, which has > been one of the arguments (maybe not presented here) against MNG. > As far as I can tell, the only real advantage HDP has over JNG are the higher bit per channel modes, and alternate color spaces. 10, 16 and 32bits per ARGB, BGRA, CMYK, etc channel is fine, but right at the immediate moment not really necessary, or displayable by most currently used video cards
JNG offers 8 or 12 bits per lossy RGB sample and independently 1, 2, 4, 8, or 16 bits per lossless alpha sample or 8 or 12 bits per lossy alpha sample. Does someone want to open up a new bug to request JNG support?
(In reply to comment #683) > I have to ask: What does this mean for JNG? Chances are, you are best with a plugin, just like MNG. (In reply to comment #682) > Transparency for sure is a requirement. Does "extension" give more power than > "plugin" in that regard ? You are probably best off with a plugin. Here are some useful docs: http://developer.mozilla.org/en/docs/Plugins
You do not want a plugin. You want to create an extension with a drop-in xpcom component that implements imgIDecoder (as the existing patch does.)
#c672, Stuart: Had you come out with that explanation two years ago... Seriously, that /is/ a good explanation in that exchange of e-mails, or at least a much better one than your tackling of things here and in the related bugs. So in any case, thanks for finally giving a decent explanation for this issue. But at the same time, I still don't trust APNG, simply because it just doesn't quite exist. The other two would have been just as fine if not better for UI items, with a possibility of them getting used on the web. And the lib would have matured with use, it's not as if every library in the world has started out robust and mature. But we've gone over this a couple times, so I don't think there's need to do so again. #c684, Sigra: Yes, I missed a 'yet' from my sentence, I'm fully aware that it will be available -- but I don't quite expect it to rise to 10% market share in a year from release... so it's a fairly irrelevant browser, unfortunately. #c688, Shawn: Do plugins give Mozilla support for seamless insertion of the plugged-in format? I seem to remember that currently, transparency isn't quite there, and you can't put them as backgrounds (think about it, translucent JNG background in a div, so you can see the page background behind it). As someone else mentioned above, it would be great if the plugin interface were improved, only then can we put MNG/JNG support into plugins (would this allow the people who want to make use of MNG in the GUI styling, to use those formats?)
(In reply to comment #687) > Does > someone want to open up a new bug to request JNG support? > One already existed, bug #88020, which I've reopened.
(In reply to comment #690) > #c688, Shawn: Do plugins give Mozilla support for seamless insertion of the > plugged-in format? I seem to remember that currently, transparency isn't quite > there, and you can't put them as backgrounds (think about it, translucent JNG > background in a div, so you can see the page background behind it). As someone > else mentioned above, it would be great if the plugin interface were improved, > only then can we put MNG/JNG support into plugins (would this allow the people > who want to make use of MNG in the GUI styling, to use those formats?) I was mistaken - the best approach would be an extension, as stuart mentioned in Comment #688. Implementing an XPCOM component (like this patch) is pretty well documented, http://developer.mozilla.org/en/docs/Creating_XPCOM_Components. If whoever is implementing this runs into to trouble, I'd suggest seeking help from #extdev on irc, or posting to the mozilla.dev.extensions newsgroup.
(In reply to comment #689) > You do not want a plugin. You want to create an extension with a drop-in > xpcom component that implements imgIDecoder (as the existing patch does.) OK. So if my understanding is correct, although the word "plugin" seems more natural at first, extensions can be made more powerful and wouldn't suffer from the same limitations as plugins (namely, transparency), right ? So apart from coding the extension, the only blocker left for seamless integration is "making unknown images support finding extensions to display them just like plugins do now" as you said in your mail I filed this enhancement request under bug 374225 - feel free to add or edit there, or even mark as invalid if there's a better way... (In reply to comment #691) > > Does someone want to open up a new bug to request JNG support? > > One already existed, bug #88020, which I've reopened. This case would also be covered by the "image decoder finder", I guess.
(In reply to comment #692) > I was mistaken - the best approach would be an extension, as stuart mentioned > in Comment #688. Implementing an XPCOM component (like this patch) is pretty > well documented, > http://developer.mozilla.org/en/docs/Creating_XPCOM_Components. If whoever is > implementing this runs into to trouble, I'd suggest seeking help from #extdev > on irc, or posting to the mozilla.dev.extensions newsgroup. There is nothing to implement, the MNG support is *already* an XPCOM component. The only things missing are solutions for bugs #374088 and #374089.
(In reply to comment #694) > There is nothing to implement, the MNG support is *already* an XPCOM component. What about comment #664? That said: > sounds OK, except that right now the current plugin available doesn't render > transparencies properly, if it's a fixable problem, that needs to happen first I see several possibilities here: (1) Comment #664 might be referring to an earlier MNG plugin implementation that is not an XPCOM component, and maybe the issue doesn't apply to the XPCOM version? (2) Maybe comment #694 is wrong and there isn't actually an XPCOM extension for MNG and the MNT plugin is suffering from a limitation of the interface? (3) Maybe comment #664 was really referring to an XPCOM extension for MNG, and there's a limitation in the interface that causes transparency issues? (4) Maybe comment #664 was wrong and there is no transparency problem? Can someone verify if there's a working MNG extension based on XPCOM already available, and whether it has a transparency problem? Is there any reason to suspect that the XPCOM interface will have any limitations compared to an in-tree implementation? On a separate note, should this bug really be marked WONTFIX? The title is "restore support for MNG animation format and JNG image format". We know that MNG isn't going back into the core, but this bug is asking for the formats to be supported -- it seems to me that getting an XPCOM implementation for MNG/JNG working automatically and transparently would resolve this bug as FIXED, and people seem ready to pursue that option. Why not leave this bug open for working toward that goal? WONTFIX implies Firefox won't ever support MNG -- if the automatic downloading and installation of the XPCOM extension works out of the box, I'd call that support for MNG, whether or not the MNG code is included in the initial Firefox download...
the plugin I referred to is here: http://entropymine.com/jason/mngctrl/ whether it's XPCOM based or not I don't know, but it does definitely have transparency issues, and also only works with the <embed>/<object> tags, not <img> Mike Hommey, if you know of a different one, linkage please
(In reply to comment #695) It's WONTFIX because Mozilla won't be pursuing it. If a third party wishes to create an extension, so be it, but they shouldn't be using this bug to update things.
(In reply to comment #695) > Why not leave this bug open for working toward that goal? WONTFIX implies > Firefox won't ever support MNG -- if the automatic downloading and installation > of the XPCOM extension works out of the box, I'd call that support for MNG, > whether or not the MNG code is included in the initial Firefox download... > I have a better idea. Why don't those of you interested in making an extension for MNG/JNG support start a new bug and let this bug die already.
(In reply to comment #696) > the plugin I referred to is here: http://entropymine.com/jason/mngctrl/ > whether it's XPCOM based or not I don't know, but it does definitely have > transparency issues, and also only works with the <embed>/<object> tags, not > <img> This is clearly a plugin. > Mike Hommey, if you know of a different one, linkage please Well, attachments to this bug are xpcom components... Latest version being available on http://sourceforge.net/project/showfiles.php?group_id=92539&package_id=97935
(In reply to comment #699) > Latest version being available on > http://sourceforge.net/project/showfiles.php?group_id=92539&package_id=97935 That's a link to the patches. Incidentally, they were broken recently by an overhaul of the configuration files, so you need to check out a mozilla version earlier than March 2007 and apply the patches to that. I won't be fixing the new merge conflicts anytime soon. I'm not sure of the exact date of the bustage but it's between March 2 and March 12, more likely the latter.
(In reply to comment #697) > It's WONTFIX because Mozilla won't be pursuing it. If a third party wishes to > create an extension, so be it, but they shouldn't be using this bug to update > things. Um, I thought the point of this Bugzilla installation was to track things that the Mozilla community was working on, not just the Mozilla Foundation itself. It seems pretty clear that there's enough interest for this to happen, and even though the Mozilla Foundation might not expend any effort on it, it's still of interest to the Mozilla community and it's still going to be relevant to the core code in one small way -- there will need to be a patch to the core code of some sort to cause Firefox to automatically search for an extension when a .mng file is loaded. (Presumably Stuart and the drivers won't object to that small hook to allow the rest of the MNG/JNG support to be externalized.) (In reply to comment #698) > I have a better idea. Why don't those of you interested in making an extension > for MNG/JNG support start a new bug and let this bug die already. It makes sense to have another bug for the extension itself, but to keep this bug open and make it depend on the extension bug. After all, THIS bug has the list of hundreds of CCs of people who are keenly interested in the outcome.
(In reply to comment #701) > Um, I thought the point of this Bugzilla installation was to track things that > the Mozilla community was working on, not just the Mozilla Foundation itself. No, the point of this Bugzilla installation is to track bugs in Mozilla.org projects. "extension to support MNG" is not a mozilla.org project. I'm sure you could apply to mozdev or something like that if you want an issue tracker to use for your project.
FWIW, I want to note that plugins can be transparent (and translucent) too, on Windows and Mac.
Do they support favicons? If so, or if not, is that a good or bad thing?
biesi: That would leave out all Unix-like systems. Not exactly fair, is it? Especially as MNG is somewhat treated as a platform-independent alternative to pure-animation Flash movies. From a technical viewpoint, plugins are components that display the contents of the <object> element. They are therefore restricted to this single usage, and making transparency possible requires an extra step. (It might also impact performance. Flash in wmode=transparent is a lot slower. I'm not sure how that compares to translucency rendered directly by Gecko.) Extensions, on the other hand, can implement and provide pretty much arbitrary XPCOM components. A component implementing imgIDecoder is a first-class citizen among image decoders. The component is only responsible for decoding the image and converting it to Mozilla's internal format. Once decoded, the image is available for everything Mozilla would do with other images. Facicons? Why not? The only question is whether Mozilla animates favicons. My guess would be no, and I think that's a good thing.
Thank you, I know what plugins and extensions are and how imgIDecoder works. No, a plugin isn't enough for MNG favicons. Favicons are basically an <img> and <img> doesn't support plugins.
(In reply to comment #702) > No, the point of this Bugzilla installation is to track bugs in Mozilla.org > projects. "extension to support MNG" is not a mozilla.org project. I'm sure you > could apply to mozdev or something like that if you want an issue tracker to > use for your project. Did you miss the point that there will be a need for a small core change to properly integrate support for transparently loading the external MNG extension? Last time I checked, SeaMonkey and Firefox were still Mozilla.org projects, and it's appropriate to use this bug to track that final integration.
This is like the blind leading the blind here. There is nothing stopping image format xpcom components from supporting transparency. Would people stop making up things and posting them here when in reality they have no idea wtf they're talking about? Thanks.
(In reply to comment #707) > Did you miss the point that there will be a need for a small core change to > properly integrate support for transparently loading the external MNG > extension? No. > Last time I checked, SeaMonkey and Firefox were still Mozilla.org projects, > and it's appropriate to use this bug to track that final integration. No, it's not. This bug is resolved. If there's a need for some other core change, go ahead and file a new bug for it and discuss it there. As I understand it, the appropriate bugs have already been filed, and the bug numbers are noted in comment 671.
(In reply to comment #701) > (In reply to comment #697) > > It's WONTFIX because Mozilla won't be pursuing it. If a third party wishes to > > create an extension, so be it, but they shouldn't be using this bug to update > > things. > > Um, I thought the point of this Bugzilla installation was to track things that > the Mozilla community was working on, not just the Mozilla Foundation itself. Straw man. "Foundation" vs. "Community" has nothing to do with how to use and not use bugzilla, as exemplified by this bug. A new bug should be used for any hook-work needed -- not this bug. That new bug is already on file, IIUC. > (In reply to comment #698) > > I have a better idea. Why don't those of you interested in making an extension > > for MNG/JNG support start a new bug and let this bug die already. > > It makes sense to have another bug for the extension itself, but to keep this > bug open and make it depend on the extension bug. No, this bug is closed and it has nothing to do with any extension or extension support bug. Even if you insist on interpreting the summary over-broadly, this bug is still uselessly long. A new bug is required just on practical grounds. But it's also appropriate given the lack of precision in your apparent reading of the summary. > After all, THIS bug has the > list of hundreds of CCs of people who are keenly interested in the outcome. This bug is full of noise, soapbox speechifying, tub-thumping, name-calling, and misinformation. It's not a free forum for reaching those hundreds of people (see the status whiteboard and use the right forum). Stop abusing it, already. (In reply to comment #707) > (In reply to comment #702) > > No, the point of this Bugzilla installation is to track bugs in Mozilla.org > > projects. "extension to support MNG" is not a mozilla.org project. I'm sure you > > could apply to mozdev or something like that if you want an issue tracker to > > use for your project. > > Did you miss the point that there will be a need for a small core change to > properly integrate support for transparently loading the external MNG > extension? This bug is not that bug. > Last time I checked, SeaMonkey and Firefox were still Mozilla.org projects, and > it's appropriate to use this bug to track that final integration. No, this bug is a bloated corpse. Use a new bug, work on keeping comments short and accurate, and lose the "Did you miss the point" rhetorical aggression. /be
biesi: Only the first paragraph was addressed to you. The rest was for the people wondering about the capabilities of the two methods. And regarding the favicon thing, I confused plugin and extension usage of the post I was answering - of course plugins don't support favicons, and you confirmed what I suspected: that image decoders do. (That's of course assuming that your second paragraph was addressed to me.) Stuart: who said anything about decoders not supporting transparency?
Animated favicons work fine. BTW, did you notice how long bugzilla takes to open this bug? I'm looking forward to see my seamonkey trying to autoload the MNG decoder when I visit an MNG site, though it probably won't work on Linux. I don't think further comments here help this. Show some compassion with poor bugzilla, and my inbox, and don't just post b/c you reach 800 ppl that way.
Wow! offline for spring break, and what do I find ... a whole lot of support for MNG. it's like a present. (In reply to comment #712) > ... I don't think further > comments here help this. Show some compassion with poor bugzilla, and my inbox, > and don't just post b/c you reach 800 ppl that way. There's been a better place to continue the discussion this whole time. It might be a better place to coordinate how to make MNG available to Firefox users. (from comment #512) > http://forums.mozillazine.org/viewtopic.php?t=115619 ^^^^^^^^^ (NOTICE THIS ^ URL) ^^^^^^^^^ Since I'm posting at all, I might as well chime in one last time: IMVHO the addon (extension) idea sounds right -- but only if the user sees something like what they see now for plugins. Otherwise I pretty much stopped trying to voice my proMNG vote anymore once I realized that the plugin option was fine, since animations really are objects in the page, and plugins usually help to render objects. I still wouldn't mind it being part of regular ol' Firefox though.
If all the energy in this bug would have been spent fixing the technical issues surrounding addons/components for image format handlers, this situation wouldn't exist. - Someone should write a patch to add custom image sniffers from external components. - Someone should write a patch to register additions to the HTTP Accept header. - Someone should write a patch to extend the plugin finder service to find handlers for arbitrary media types. Those three things would be useful for many other image formats other than MNG -- MNG, JNG, JPEG2000, TIFF, HD Photo, etc., etc. could all then be implemented and enjoy decent support. I don't see any reason why any of the above three patches would not be accepted, provided that the revelant module owners are talked to and are involved in the design, and that issues such as security and user experience are taken into account. Instead, there are people throwing themselves against the brick wall that was erected around Firefox shipping with default support for MNG, which did not happen for Firefox 2 and will not happen for Firefox 3. Should there be a massive drive towards MNG on the web in the next two years, sure, the issue would be revisited, but for now, and for the past few years, supporting MNG does not make sense. The tinfoil-hattery conspiracy theorists really need to take a break.
(In reply to comment #714) > If all the energy in this bug would have been spent fixing the technical issues > surrounding addons/components for image format handlers, this situation > wouldn't exist. Agreed. But then immediately you turn around and check in a new embedded format, APNG, without trying the addon approach.
Glenn, your software is really great, widely used, and widely admired. MNG, however, is not. It's a bazooka when all that's wanted is a fly swatter. APNG is that fly swatter, it's backwards compatible with the existing PNG spec and decoders so that APNGs will display everywhere while MNGs are invisible without explicit decoder support (APNGs will be visible in IE, but not animated, and that'll put pressure on MS to support them). The APNG spec has been being developed for quite a while now, has had a lot of input, a lot of thoughtful revisions. It's clean, simple, does what is needed without 15 other tricks. It looks like you're taking this far too personally, when in reality it's a technical issue. Don't take it personally, no one is insulting you personaly regardless of how it feels. MNG is just more than is wanted or needed. Maybe in the future if MNG matures into a more cohesive format, there can be a second look. FWIW, my statements hold no water with Mozilla, and are only my own opinions.
Neither is APNG a fly swatter. mPNG, currently being discussed by the PNG group, is, and has the same visibility features. See ftp://ftp.simplesystems.org/pub/png-group/documents/png-mpng-proposal-20070321.txt Feel free to morph this bug into a request for mPNG support. Glenn
Don't morph bugs. If you want to file a new bug go ahead, but from where I stand we now have a working APNG implementation in the tree and we don't really need a second or third PNG animation format.
Just an observation – is MNG a forbidden word in wiki.mozilla.org http://wiki.mozilla.org/Special:Search?search=APNG&go=Go Returns 1 Article title matches and 5 Page text matches. But poor MNG returns - http://wiki.mozilla.org/Special:Search?search=MNG&go=Go No page title matches No page text matches Note: unsuccessful searches are often caused by searching for common words like "have" and "from", which are not indexed, or by specifying more than one search term (only pages containing all of the search terms will appear in the result). Yet it does appear twice in http://wiki.mozilla.org/APNG_Specification
(In reply to comment #719) > No page title matches > No page text matches I know what you're thinking, but your cause for concern is unwarranted. Three characters is simply too short to search on. You'll find that neither PNG nor XML return any matches either. (In reply to comment #714) > If all the energy in this bug would have been spent fixing the technical issues > surrounding addons/components for image format handlers, this situation > wouldn't exist. I agree in principle, but it's really not a valid expectation on the whole. It only applies if everyone in the discussion has the know-how and aptitude to help out in this capacity. I expect that's actually the vast minority... A lot of people here _can't_ expend energy in that direction, and yet they're affected regardless. Telling non- or inexperienced developers to stfu and stop posting their concerns sort of defeats the purpose of having a public bug/feature tracker to solicit reports and feedback.
Has MNG support been reevaluated since XULRunner came along? Even if MNG support is not valuable for the web or Mozilla apps, it could still be useful for other XUL apps like Democracy Player, Joost, and Songbird. If there's really any push for developers to use XUL for their own projects, it would be reasonable to reevaluate MNG support. What's right for Firefox isn't necessarily right for XULRunner.
The key to any evaluation is basing it on what requirements a developer has. Start with the real-world requirements, not with the technology. The question is not whether MNG is theoretically useful, but whether it solves a real problem that already exists. I haven't heard from any developer of XULRunner-based apps that MNG is the solution to a problem they currently have (whereas a lot of said developers are using SVG to pretty good effect).
(In reply to comment #721) See http://wiki.mozilla.org/XULRunner#Versioning and note how the XULRunner version tracks the Mozilla milestone number (1.8.1, 1.9), which reflects as the Gecko rv: comment in the User-Agent: header. We are not going to add features to XULRunner not in Firefox without a lot of thought and care about how that might or might not fatally distort the Gecko rv: relation to XULRunner's version. This should be known; perhaps it's not documented enough yet. Joost and the others you list do not care about MNG. XUL does not depend on MNG either. This bug is an old carbuncle on the side of bugzilla. Let it scar over, please. Put energy into plugable image decoder discovery and integration. /be
Reading the justification for this bug being closed. How is APNG a replacement for JNG? It is still possible to failover from JNG to a dithered PNG or GIF if the idea of "pressuring" as mentioned in comment #716 is desired. Anyway, seems like the overall strategy with this bug was ignore it for a while, then close and hope people lose interest. Well, let me register my disappointment as a user, at least. I suppose the linux world can still support JNG as it has in the past with distro patches.
I'm just restarting this comment for the 59th time in the last week or so........ Can we please all agree that this is going nowhere? The decision not to support MNG natively has been made and we have been offered an alternative. The big question is only, is it a workable alternative and who has the ability/time to spend on building it? Since it's proposal I haven't been made aware of any new bugs opened to even start this thing. If they have then please let me know as I'd like to listen in :-) Now as for APNG, can we please move that discussion to bug 257263 and let this one rip? There are some things that people need to be aware of that are not getting addressed on here, because it would definitely defeat the purpose of a bug repository. (allthough I presonally think good ol bugzilla is a little more than that) The short story (but again please go to bug 257263 for the long story): 1) APNG may not make it into the PNG standard 2) other options are currently being discussed that have a much better chance of becoming an official PNG extension 3) I am offering help to write/extend GUI tool(s) to create files according to whichever option makes it into the PNG standard (this could be ready within 2-4 weeks after the PNG spec modification has been made) So again, let's drop this bug once and for all. I wrote the damned MNG library and please take it from me that I've truely had it with this endless discussion over here!
(In reply to comment #725) > Since it's proposal I haven't been made aware of any new bugs opened > to even start this thing. If they have then please let me know as I'd > like to listen in :-) Well, I'd say : 1) Finding the suitable extension is bug 374225 2) Allowing it to register a new image format is bug 374088 3) Writing the extension itself doesn't belong in bugzilla if I'm not mistaken, as it'd then merely be an "add on". So would be JPEG2000, DJVu, Microsoft's HD Photo, Adobe's DNG (or any other future format) decoders... I think it's a good starting point...
My MNG gallery @ http://ctho.ath.cx/tmp/mng/ finally works, in Firefox 2.0.0.3! Thanks, Stuart! Why didn't this get announced in the release notes though?
URL: http://www.libpng.org/pub/mng/ → http://ctho.ath.cx/tmp/mng/
(In reply to comment #727) > My MNG gallery @ http://ctho.ath.cx/tmp/mng/ finally works, in Firefox 2.0.0.3! > Thanks, Stuart! Why didn't this get announced in the release notes though? > Ha-ha! Very funny. Don't You think it's a little bit too much?
Mike Beltzner says Hi from FSOSS.
Do not depend on duped bugs
Depends on: 391667
No longer depends on: 374088
No longer blocks: 326817
Note that bug 374225 ("Make unknown image formats find an extension to display them") is now RESOLVED WONTFIX.
You don't restore only the JNG format? You cannot restored only JNG, nowadays excepte Flash with the lossy compression for PNG, there is no equivalent. They are obliged to put Flash image... JPEG with transparence, it's for when? :\
You don't restore only the JNG format? You cannot restored only JNG, currently except Flash with the lossy compression for PNG, there is no equivalent. They are obliged to put Flash image... JPEG with transparency, when this will be? :\
Célian, while I strongly agree that APNG is a poor replacement for the features of MNG, particularly poor choice given how small MNG was, especially when it replaced PNG... I would not resort to Flash so quickly. It seems to me you could achieve the same thing with a canvas tag and two images, one serving as the alpha channel to mask the other, the JPEG. Granted, there is no library to make that simple and convenient, but it seems it should not be that hard. Since it probably would not require sampling the canvas pixels, it might even be iecanvas compatible.
It's little complex. 1. Img or url() → MyImg.jng 2. Object → MyImg.swf 3. Canvas → Two pictures (color & channel) with a script It's not a solution for beginner and not usable in CSS.
I certainly agree about the complexity, I'm the first to lament the death of JNG. If the script does the heavy lifting I'd say canvas is more accessible for beginners than figuring out an SWF. A properly packaged script would auto-magically make translucent a JPEG on the page with the correct extension and a 2nd mask image. Just requires someone to do it. And it would be *more* usable in CSS than an swf since the JS could hook into the CSS as needed, and the canvas is easily transformed by the CSS. But, yes. JNG is far superior.
I certainly agree about the complexity, I'm the first to lament the death of JNG. If the script does the heavy lifting I'd say canvas is more accessible for beginners than figuring out an SWF. A properly packaged script would auto-magically make translucent a JPEG on the page with the correct extension and a 2nd mask image. Just requires someone to do it. And it would be *more* usable in CSS than an swf since the JS could hook into the CSS as needed, and the canvas is easily transformed by the CSS. But, yes. JNG is far superior. And even though I question the reasons/politics for killing off MNG, we really should let this poor dead bug rest in peace and just use the forum as requested in the whiteboard. Ok?
This is THE defacto forum for expressing the case for MNG/JNG's re-introduction into Firefox. It has served over 10 years as such, and currently has 707 supporters waiting with bated breath for this bug to be fixed, once and for all. What's sad is the fact we're actually having this conversation. Eventually everyone's just going to switch to Chrome and IE for MNG support anyway.
For everyone that is writing needless comments, I suggest that you read this: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html You are not helping to fix this bug, instead you are making it less likely it will ever be fixed. No other major browser vendor supports this except Opera. Why should be be supported if: 1. There are other ways of giving designers the features present without adding a new standard into the mix. 2. There are few other browsers that support it, leading to minimal use cases. I'm sorry people but the fact that this has been marked as wontfix means you will have to demonstrate a significant use case that cannot be filled by another standard. Unless you can do that no developers will look at this twice. Either way, please stop spamming this bug with needless comments. Thanks!
(In reply to comment #740) > For everyone that is writing needless comments, I suggest that you read this: > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html > > You are not helping to fix this bug, instead you are making it less likely it > will ever be fixed. > > No other major browser vendor supports this except Opera. Why should be be > supported if: > > 1. There are other ways of giving designers the features present without adding > a new standard into the mix. > 2. There are few other browsers that support it, leading to minimal use cases. > > I'm sorry people but the fact that this has been marked as wontfix means you > will have to demonstrate a significant use case that cannot be filled by > another standard. Unless you can do that no developers will look at this twice. > > Either way, please stop spamming this bug with needless comments. Thanks! Hey Ryan this comment of yours seem strange, "1. There are other ways of giving designers the features present without adding a new standard into the mix." Maybe you don't understand that mng format was supported by firefox and removed, even though some hardworking person/people, not me, step up to resolve issue such as there was not maintainer etc. I now mainly use google chrome, I moved from firefox due to flash problems killing all my tabs. I was just think that had the effort that went into creating a new standard call apng was put into png/mpg instead, I might be using firefox more.
(In reply to comment #741) > Hey Ryan this comment of yours seem strange, > > "1. There are other ways of giving designers the features present without > adding > a new standard into the mix." > > Maybe you don't understand that mng format was supported by firefox and > removed, even though some hardworking person/people, not me, step up to resolve > issue such as there was not maintainer etc. I am quite aware of that. I am not sure of the exact reason why it was removed, it was probably removed because either nobody was maintaining it, it was adding complexity or adversely affecting the code base in some way (e.g. security issues) or because there was nobody using it. Mozilla recently removed XBM support for some of the above reasons for example. > > I now mainly use google chrome, I moved from firefox due to flash problems > killing all my tabs. That has nothing to do with this bug. I will not even comment further on it. > > I was just think that had the effort that went into creating a new standard > call apng was put into png/mpg instead, I might be using firefox more. The developers obviously say an advantage in the APNG method. I am not one of the ones who wrote the standard, however they obviously believed it to be superior or they would have not used it.
(In reply to comment #742) > I am quite aware of that. I am not sure of the exact reason why it was removed, > it was probably removed because either nobody was maintaining it, it was adding > complexity or adversely affecting the code base in some way (e.g. security > issues) or because there was nobody using it. Mozilla recently removed XBM > support for some of the above reasons for example. The reasons have been hashed through several times is this thread, and while not everyone agrees to them, the maintainer seem unlikely to change his view. The way forward seems to be to provide MNG as an extension. After all, mozilla is an extensible browser, isn't it? Unfortunately, this would require bug #374225 to be fixed in order to work well, and that one is also marked as WONTFIX... :-( > The developers obviously say an advantage in the APNG method. I am not one of > the ones who wrote the standard, however they obviously believed it to be > superior or they would have not used it. They believed it to be a better fit for their particular needs, and were probably right. The needs of the users may be quite different though.
I've asked Brendan to some along and explain Mozilla's position on this, whether he will or not is another thing. I'm sure he will give a final answer, one way or another for you guys so hopefully I will see no more bug spam. Let's wait and see what he says.
Ryan, I don't think a negative final answer would change anything. In fact, I'm sure it's somewhere up in the comments, since this bug is marked as not just RESOLVED, but actually VERIFIED as WONTFIX. The thing is that there is some interest in MNG and JNG being supported, and since votes seem to be ignored, the only way for people to show their dissatisfaction is to comment. I wish those votes we place would actually mean something to the developers... Perhaps that would indeed mean less bugspam. Because so far they generally seem to be ignored.
APNG brings no solution for lossy compression with tranparency (JNG). No format allows it, it's the only lack for images.
Developers have very little free time, they work based on priorities and while I am sure they would love to fill request features - there are much more important things that need to be done for features that are of more use for, or affect, far more people. If someone were willing to step up and take this on, then maybe the devs would pay more attention and give it consideration. But the devs DO NOT answer to anyone here, not you and not me. If you don't want to step up and take responsibility for this, why should they? Just think about that before anyone makes any more pointless comments on this bug. I think it has been spammed enough already and I for one will make no more replies to this bug unless I have something to contribute.
(In reply to comment #747) > Developers have very little free time, they work based on priorities and while > I am sure they would love to fill request features - there are much more > important things that need to be done for features that are of more use for, or > affect, far more people. The official reason was that MNG/JNG component was too big (in size). There was a guy who took over and addressed the problem. Mozilla team ignored the solution and pushed for APNG, which at the moment is only supported by Firefox and Opera. The PNG group rejected APNG. More at http://en.wikipedia.org/wiki/APNG#History Enjoy.
Ryan you say "Developers have very little free time", did you know that developer who removed mng is also the creator of apng. From http://en.wikipedia.org/wiki/APNG Stuart spent a time removing all the mng buttons from firefox so the way was open to remove the mng code. Stuart created apng to replace some of features of mng and add a great feature of allowing a default png image. I really do appreciate the work that Stuart and others have put into firefox and mozilla, I think it just looks wrong that Stuart is the named as developer on this bug/request that wont be fixed. Why can't there be a firefox that supports both apng and mng.
How about the plugin solution, which was mentioned a few years ago? What's the current status?
See comment 710 and comment 723 and stop adding new noxious gas to this bloated corpse of a bug. /be
@751 No trolling, please.
(In reply to comment #752) > @751 > No trolling, please. Your account is now disabled. Any other violations of the Bugzilla Etiquette in this bug will result in instant account disabling. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(@750 efforts to get pluggable image formats working seems to have stalled when bug #374225 was WONTFIX-ed) This bug thread re-awoke with a fairly reasonable concern about JNG. It's clear that the whole animated PNG: APNG/MNG/compromise-MNG-replacement impasse is deadlocked and _well_ beyond the scope of bugzilla, but what's been lost in all this is a static lossy image format with an alpha channel. It seems crazy that in 2010 the web needs to resort to canvas/JS for this, or that web devs resort to flash. Why can I not set a JPEG background image which is not rectangular in my CSS? I have had several projects which have had to recode original JPEG imagery into PNG for the sake of an alpha-channel. IE now supports JPEG-XR (a patented, wavelet-based image compression format which does include alpha); what is the open web's offer? I think we need a separate bug which is an RFE for JNG without the baggage of libmng and the 750 comments. The case is for JNG is much more compelling than for MNG. As far as I'm concerned the web has moved on since 2001. Then, a fully featured MNG had the potential to replace GIF and many uses of flash, now, vector animation/video is far more important and animated images somewhat less relevant.
I strongly agree with comment #754 - there are a few cases where MNG might be nice, but most can be worked around with use of <video> (unless alpha is needed), or GIF, or a PNG sequence + a touch of javascript, or vector art, or canvas, or, (rarely due to lack of support) APNG. JNG on the other hand, is much harder to replace. While I'd still love to see something a bit more sophisticated than APNG, heck, maybe something APNG-like but w/ a touch of jpeg support... if it is an all or nothing thing, I would drop that in a heartbeat just to get JNG. Heck, I can animate a JNG with javascript too ;)
There is an RFE for adding JNG support as bug #578183 Any further discussion of JNG is much more appropriate there. I suggest those really keen on seeing MNG on the web attempt to get it added to the Chromium codebase then popularise it on the web through use. It would be a quicker route to support than adding to this bug.
JNG support would be fantastic, but I sooner sense a new AJPG would be developed just to spite the coder who developed libmng. Speaking about MNG popularity on the web, I was of the impression that MNG is widely used across Asian websites, and hence the creation of Iceweasel and its inclusion into Opera. Definitely getting Google on board would be a plus, but I don't understand why Mozilla should have to be a second rate browser that merely panders to everyone else. And to top it all off, if it weren't for libmng's removal, thousands of Firefox users would not have been infected with the PNG virus we saw a couple years back. Mozilla could have been THE ONLY BROWSER standing proud amongst the crumbled masses, to say, "Get Firefox. Stay Virus Free." Forever remember kids. libpng tarnished our record. libmng would have kept it spot free. I cannot forgive that failure of arrogance.
(In reply to comment #754) > (@750 efforts to get pluggable image formats working seems to have stalled when > bug #374225 was WONTFIX-ed) Actually, with bug 374088/bug 391667 being fixed, pluggable image formats should just be possible.
(In reply to comment #758) In theory, yes. In practice, nobody will use MNG/JNG without the Plugin Finder Service working for the img tag. As it is, you'd have to use object tags (eww) and/or put a note on the page explaining what to do to make the images work. Bug 374225 is necessary for mainstream use.
I suggest that those who want JNG support should go and vote on bug 88020. This bug is a meta bug in a sense that it asks for two distinct features.
Depends on: 88020
Есть решение проблемы - userscript. http://jngw.500mb.net/ujng/
a fast translate, for those that dont want to do online translations: There is a solution to the problem - userscript. http://jngw.500mb.net/ujng/ on the site we have: JNG from User Script JNG See this picture of the old format JNG? No? Then check this [script] for Firefox. Required to support SVG masks and filters to HTML, and the presence of extension Greasemonkey.
Christopher: what now?
New JNG page: http://jnglike.site40.net/ Works with JavaScript.
MNG not have script.
I made Emscripten port of MNG. After 17 years from creating this issue.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: