From the above, it seems PNG transparency is not supported. It would be nice to have real alpha-channel support too, which I believe PNG offers.

By real alpha-channel support, I mean 8-bit transparency (I think those mean the same thing...I'm not all that sure of this stuff). Someone commented on www-style today that gamma-correction is also essential. See the thread beginning at: http://lists.w3.org/Archives/Public/www-style/1999Feb/0004.html

I concur with David- that was the purpose of creating PNG - making a new graphic format solely for the Web. Being able to make use of PNGs many features, requires a full implementation in the browsers.Here's the recommendation: http://www.w3.org/TR/REC-png

see test pages for gamma and for transparency in PNG http://www.w3.org/Graphics/PNG/Inline-img.html http://www.w3.org/Graphics/PNG/all_seven.html http://www.w3.org/Graphics/PNG/inline-alpha.html http://www.w3.org/Graphics/PNG/inline-alpha-table http://www.w3.org/Graphics/PNG/inline-alpha-table32.html

Yet another test page: http://www.cdrom.com/pub/png/pngs.html (I also filed bug 3195 on the progressive display of the interlaced PNG in this page.)

kevin, you should coordinate wil pnunn to make sure that the interfaces to the image lib can deliver a full alpha channel (i think that is the case) and then augment the image rendering code/blender as necessary.

The URL above is misleading since the PNG smiley doesn't *have* transparency; thus it will always look "wrong" compared to the GIF version. I've just sent e-mail to Glenn suggesting he fix that; in the meantime, note that Mozilla has supported binary PNG transparency since the 19980331 release. As for 8-bit alpha transparency, Pamela has been recently updating imagelib to handle that (possibly in conjunction with michaelp), and as soon as that's working/checked in and we can come up with a reasonable RGB+A interface to il_emit_row(), alpha PNGs will be looking good. For testing with minimal interference from other effects (OBJECT bugs, etc.), I recommend this page: http://www.cdrom.com/pub/png/pngs-img.html Each of the four images at the bottom can be clicked for a larger, single-image test page.

The PNG icon at the URL above is now fixed, and Mozilla displays it identically to the GIF.

The PNG's have transparency..

The 8-bit transparency still isn't working (see the toucans in the second test page). Is there another bug on that or should this one be reopened?

The PNG do support transparency, there is another bug that not all depths show the tranparency, but this bug should be ok because the tranparecy info is getting into Gecko. The 8 Bit should show up as soon as the other bug is fixed.

David is correct: this is the only PNG-alpha bug in Bugzilla, and it is not yet resolved. Basic transparency has been there since the 31 March 1998 release. Note that this has nothing whatsoever to do with the bit depth of the display; it is about about displaying 8-bit (or 16-bit) alpha ("partial transparency") correctly, on a per-pixel basis. Reopening... Greg

Pam, can you tell me if there is a diffent code path to reading in an 8 bit PNG, and if the alpha or transparency would change. Does a different kind of image (nsIImage) get created when the depths of the monitors change. I do know that we do not support alpha very well at all the depths. Alpha has been present since 98, but we have not completed all the code paths. Just because 8 bit GIFS work does not mean that 8 Bit PNG's will work the same since there are many more colors that can go transparent. I know that we do not support multi apha at 8 bits properly today.

dcone: whoa. We need to clarify some terms here. Alpha channel is supported. but the 8 bit value of transparency for each pixel is THRESHOLDED to be 100% transparent or 100% opaque. Any pixel can have this channel applied to it. In gifs, only one color is mapped as transparent. In the current code base for windows, there is a switch in the pngcom code that will turn on alpha for an 8bit mask instead of a 1 bit mask. The alpha displays for 256 levels of transparency....over any background. IE, I believe doesn't even try to address the issue of alpha transparency over a frame or window background. The code to implement 8 bit masks is not yet checked in on linux and Mac, because the Mac is giving me fits when I create an 8 bit mask structure. (Any mac help would be appreciated.) The code I have for linux, builds the 8 bit mask, but doesn't have a nice mask functions like those available on mac and windows. There are better solutions for this, but other projects have priority over this one. If you are on a wintel machine, try out the switch: Change the ifdefs in mozilla/modules/libimg/pngcom/ipng.cpp, line 128. -pn

Could whoever marked this invalid please explain why? Thresholded alpha is a bug; it's not fixed yet; and 3013 is the only Bugzilla bug that addresses the problem. Ergo, nothing is resolved. What am I missing here?

Thresholded alpha is NOT A BUG. It may be an implementation you dont like, but it is not a bug. -p

"It's not a bug, it's a feature!" Thus, re-opening as a feature request, for after Pam has finished more critical functionality.

[Re-opened as RFE, M20.]

Ask any user on the planet; I guarantee you that 99% of those who know what alpha is will agree that thresholded alpha IS a bug. If users wanted their images to look like crap, they'd have made them that way in the first place. Call it whatever you want, but I intend to make sure it's working by M11.

Its a pleasure to work with you, Greg. -p

Apologies to all for the unnecessarily strong language. (Private message sent to Pam.) Greg

*** Bug 2587 has been marked as a duplicate of this bug. ***

I sure hope the 8bit alpha is going to be unthresholded before beta. It is absolutely important for writing nice XUL which considers user preferences for UI-colors. (so button-images can be anti-aliased and can have a drop-shadow)

*** Bug 14926 has been marked as a duplicate of this bug. ***

If you're wondering why this bug suddenly got such an insane number of votes, it's because it just got Slashdotted ... http://slashdot.org/article.pl?sid=99/10/31/1337238

True alpha blending could be done post-layout if bitmapped information on the current display is stored in layers with alpha support (similar to imlib).

...not that that should invalidate all these votes ... it's just an indicator of how badly this bug needs to be fixed, so that all of us can move to a better, smaller, faster, etc, etc, web.

Changing OS from Linux back to All since this is still a cross platform issue. However, I believe there is a build switch to turn on 8 bit alpha in Windows. I also heard that some work was done to get it to work on Mac. What is the status of 8 bit alpha across the 3 main platforms? Is Linux the only platform lagging now? Would it be possible to get this turned on by default for the Windowss builds at least?

ssym: Of course the votes are valid. I'd like to see this bug fixed too, but all my Browser votes are busy. :-) Mozilla is making a great show of implementing the W3C standards of HTML, CSS, and XML -- and more importantly, implementing them *correctly*. It's worth reiterating that PNG is also a W3C standard. Whether the lack of 8-bit alpha transparency is an `incorrect' or an `incomplete' implementation of PNG is a semantic issue, but I think most people would call it `incorrect'. Also, the PNG format is in the public domain whereas the GIF format (technically) is not. The relevant article: http://slashdot.org/article.pl?sid=99/10/31/1337238

Here's the deal, folks: plain xlib and (last I checked) gtk provide no support for alpha compositing, which means the current platform-dependent approach Pam has implemented (under http://lxr.mozilla.org/seamonkey/source/gfx/src/) simply will not work for Linux or other X platforms, nor for OS/2 and possibly BeOS. The code that knows about Mozilla's layers of stuff (which, keep in mind, can be moving around a la Demo 10) all lives up in the vicinity of http://lxr.mozilla.org/seamonkey/source/view/src/nsView.cpp and similar regions; *that's* where it has to be handled on X (calling back to the software compositors in gfx/src, which, if they don't exist yet, are trivial to write). The problem is that I have absolutely no clue what "kids" are (nsView.cpp), how they relate to image containers (http://lxr.mozilla.org/seamonkey/source/modules/libimg/), and how the code gets from the high-level kids view down to the low-level image-container view (i.e., a call stack). This is something that other folks could help with (hint hint), even folks who never download a shred of CVS'd code or compile anything--LXR provides a real-time view of the code base. I simply don't have time to try to trace through the code manually, and ongoing rewrites of the networking code and other things broke my Linux/libc5 builds two or three months ago. Further information (including comments on bug 3195, which is also directly related to masks) is at http://www.cdrom.com/pub/png/pngmoz.html . Greg

Folks, if you want this fixed --- please, just connect with newt, and help him fix it. Lots of "we want this fixed" bug comments won't magically make the code appear any faster!

are you volunteering to write some compositing code for linux us to use on linux?

FWIW, I implemented code in nsImageMac.cpp to do 8-bit alpha blending on Mac. This is not checked in yet.

Looking through the png application lists, the only web browser that supports alpha 'properly' is arena. So I grabbed it and tried it. It's AMAZINGLY slow. I think we have a tradeoff between a fast browser and a fully PNG compliant browser. I have withdrawn my votes from this bug, as there are many more important ones.

Pavlov: it's already there, just not totally enabled. See Do24BlendWithMask() and Do8BlendWithMask() in http://lxr.mozilla.org/seamonkey/source/gfx/src/nsBlender.cpp . That part is easy (and so is adding Do32BlendWithMask() and Do16BlendWithMask, if there's any need for them, which I assume there is). Getting aMImage (or mDestBytes in Blend(), a.k.a. the background pixels) is the hard part--that's where the high-level view/src code comes in, because apparently there's no callback for a given piece of low-level code to say "give me the current background at this location, with these dimensions, so that I can composite against it." And it looks like there needs to be yet another variant of Blend() since currently it isn't even given a pointer to the alpha mask, but that should be pretty easy to write, too. Yarn: Arena is slow at everything; alpha-blending is certainly not the (only) reason. You can expect Demo10-like speed for Mozilla's alpha blending. Only a few more cycles per pixel are required, and those temp conditionals can be removed. In fact, a little MMX magic would do wonders for the blending code. I'm kind of surprised that nobody's done it yet, since I recall someone else suggesting it almost a year ago. Btw, even WebTV (a very low-end platform) does 32-bit RGBA correctly--and unlike Arena, it uses the specified web-page background. But for X, Arena is/was the best approximation (RIP). Greg

Another testcase: http://www.w3.org/Graphics/PNG/inline-alpha-table to test compositing against different backgrounds

I see someone was saying that Arena does alpha PNG but is slow. It is slow, but that is because dave Raggett wrot eht code in 2 weeks (its the first web browser to support tables) as a demo, and bits got added and added - the code is ****, basically, although by the time we stopped work on it the PNg support was pretty good. SVG viewers do support alpha compositing with PNG onto arbitrary backgrounds (and hey, they have to support rotation, skewing, and bicubic resampling of the PNG as well) so it isn't necessarily hard or slow.

*** Bug 19283 has been marked as a duplicate of this bug. ***

*** Bug 19539 has been marked as a duplicate of this bug. ***

*** Bug 19538 has been marked as a duplicate of this bug. ***

*** Bug 19538 has been marked as a duplicate of this bug. ***

Here's a possible cross-platform solution which would work with the assumption that images only appear over a background region (body or table cell). That is, they will not render over other html elements. When the layout engine creates an image, it can tag the image with a pointer to the underlying surface (solid color or another image) and the relative offset of the origins. At render time the image can be alpha composited to the underlying surface and cached for later use. Images will need "dirty bits" to note when the image data has changed or the images have moved. At render time the image will recomposite if either its own or parents dirty bits are set. Before I attempt to write the code to implement this, could someone tell me whether my original assumption is correct?

The assumption that the image will always be over a constant background is definitely not correct. It could be over: * a background image * text or changes in background (by positioning or negative margins) * borders between backgrounds (if its partly overflowing a container) and there are also a number of cases where it's not trivial to determine what the correct background color would be. In particular, when content overflows its container, the relevant background wouldn't be (completely) that of the container. I'm not sure whether it would be better to have a solution like this or threshholded transparency (as it is now).

Per e-mail from Greg, he has relinquished PNG component ownership; thus, reassigning assigned bugs to ImageLib owner.

*** Bug 26894 has been marked as a duplicate of this bug. ***

Sorry to add a comment that doesn't actually contribute to the resolution of this bug, but I would like to point out that a large number of web developers (including, for example, a significant number of the participants in this weekend's mozillaZine discussion on "most wanted feature") consider this bug to be of very high importance. There are so many obvious examples of where this would be incredibly useful, from adding shadow effects against arbitrary backgrounds to producing anti-aliased images that don't have to be created separately for every background they may be rendered against. Even mozilla's *chrome* would benefit from it - the use of alternating lines to give some sort of illusion of semitransparency is a hack that just goes to show how much this is needed. Do you want web page authors to have to require pixel-perfect alignment to get an effect that is used in the browser's toolbar? I'll draw these comments to a close now as I know bugzilla is not a place for advocacy. But please bear these considerations in mind; scheduling this for M20 is not acceptable to the web developers who have been crying out for standards support for so long -- and holding out Mozilla as the best hope for getting them.

With all of the advantages PNG file formats bring to designers and users, it is quite strange that it still doesn't work properly in todays browsers. If antone was to win a browser war....this would be the ideal weapon, since as you know, the designers deside of the winner when building the Sites to be more compliant with one browser or the other. I have been one of the first designers and web programmer anywhere, and i've been using PNG file formats since its very first peek, and must tell you that it is as important as Flash and Java can be. The fact that the user can download a plug-in that works perfectly well, prooves that it isn't such a stretch for either browsers to implement it. In conclusion, it's more then time someone did something about this. Styles

styles@ergonet.com: So, are you volunteering to write the code...?

So, any GIMP programmers out there, we need you! (I guess with the problems of turing GPL into NPL we couldn't just copy the code straight out :)

elig@netscape.com ---> If they can afford it, and thats the only way it'll ever be done, then i'll get the people needed and have it done. But i dought thats the reason, its most likely because it is either too time consuming, too expensive, or not in theyre priorities.

Stupid idea here.... Why not just implement PNGLive 2.0b5 for the time being. let it be plug-in that comes included with Netscape for Win9x/NT/2000. this might be a good start. if all it meens is that we have to put it in <EMBED> when creating a site, it doesn't meen much more work for designers and might be worth it. Also, anyone out there have the source code for this plug-in ? and the version 1.0 ? Maybe theres still something to do with it, it was after all....the best one yet.

Elig, I think what he's saying is that it's foolhardy for Netscape to release a browser without PNG alpha at the time when they desperately need to regain market share. If someone outside of Netscape doesn't do it, then Netscape should do it, if only for Netscape's sake. It's up there with CSS support as a necessity.

matty@box.net.au: So, are _you_ volunteering to write the code...? ;)

Is there some documentation available as to where one should poke?

Yes, see Greg's page <http://www.cdrom.com/pub/png/pngmoz.html>.

Some information is here: http://www.cdrom.com/pub/png/pngmoz.html Unfortunately, figuring out how to translate from the highest-level structures (which is where alpha is/should be handled, since that's the only place that can do software alpha on X or bad Windoze boxes) down to the gory details in ImageLib and gfx/* (which is where PNG and platform-dependent graphics code lives) is non-trivial. What's needed is someone who understands the overall structure and flow of control in Mozilla, or else someone who can take the time to trace the flow across possibly megabytes of source code. It could probably be done in a weekend, maybe even just a few hours, but I ran out of time before I ever had a chance to try. Btw, my knowledge of the code is a few months old, so it's vaguely possible that things have gotten significantly better since I last looked.

My interpretation of this problem is somewhat different than Greg's. This may be due a fundamental misunderstanding of mozilla on my part, but maybe these comments will be useful to someone. Greg argues that the alpha transparency needs to be done at a high level, because not all the underlying graphics APIs are capable of doing compositing themselves (X being the usual example). My thinking is that the gfx layer is a more natural place for the alpha-blending responsibility, in that it should take images with an 8-bit alpha mask and be capable of rendering them in a composited fashion. This would make for simpler code and is really the only way of dealing with the case of an image overlapping text. From pnunn's comments on 1999-09-01 there is already some #ifdefed code that will pass 8-bit alpha masks along with images. Looking at the code it references I don't see the ifdefs anymore, but hopefully this code is still around. Maybe pnunn can comment? It looks like the win32 and mac gfx layers can deal with an 8-bit alpha mask already by mapping it to alpha-capable API calls on those platforms. This leaves gtk as the only tier-1 platform currently without this capability. gdk doesn't have any function for reading back an rgb image, but it does have gdk_image_get that returns the data in a visual specific format. You'll need to map this through the associated colormap and visual to recover an rgb image which can be software composited with the new image, then written back to the window.

To be more specific: you can't composite anything until you have something to composite against. The gfx code doesn't know anything about the various layers in the page (some of which may be moving or animated, a la Demo 10); only the higher-level code knows that. That's the part that really needs the work. Once you have some way to send the alpha channel all the way back up (instead of flattening it right away in gfx), you can then send it back down WITH background info and do the compositing in gfx as you suggest. But the gfx code itself needs very little work--the compositing code either already exists or else is an obvious and simple extension of other code that exists. The hard work is making the connection to the high-level code. There's no such thing as an image container in nsView.cpp; just "kids." Note that the Mac and Windows code can get away with the lazy approach since the underlying graphics engine of the OS supports alpha blending--in effect, you can use it to "remember" the underlying image layers at each frame. That's impossible in X (which is the primary display system for all Unix and OpenVMS systems), OS/2, and probably quite a few other operating systems. If you still think I'm missing something, don't be shy about telling me/us! I've been wrong before... Greg

It's my impression that the viewmanager[2] sorts the objects in a back->front order, so the gfx layer just has to composite atop what has already been drawn into the framebuffer.

I was just trying to understand how the view manager works, and I noticed there's some disabled code in ViewManager2 dealing with translucent views: http://lxr.mozilla.org/seamonkey/search?string=SUPPORT_TRANSLUCENT_VIEWS Anybody know what the status of this code is? It seems like it's written to do part of what's needed here. (See in particular the code in RenderDisplayListElement.)

Actually, it looks like that code might be for dealing with views of fixed opacity (that's not 0 or 1). But it could be a good place to start, although one would need to get the mask in the right place...

ok. Here's the deal. I already had a alpha version working on windows and simon had it working on mac. Newt didn't like this solution and later made changes that broke these versions that use the platform specific calls for alpha. These changes were not meant as a permanent solution but as a stop gap until the gfx code could be modified to deal with true alpha blending rather than layer transparency as it does now. I can get these changes back in if I can get in the witness protection program from other bugs,gripes&other time stealers. Adding comments as to how much alpha transparency is desparately needed doesn't help the cause. It just eats up time I could spend on code. I want this in as much as anyone. Alphatransparency is easy if you know exactly what the background is going to be. We have dynamic layers. Any alphatransparency has to work with the compositor because of dynamic layers. (and I don't mean layers tags here.) -P

In responce to that. Any half decent Web Designer should have the capacity of adapting to certain bugs, I dont think we're asking for something perfect, just for something that works well enough for us to use. I call it cheating the programmers. If something (inserting PNG Alpha images) cannot be done because of the way other elements react or interact with it, then the designer should adapt the element to avoid it without killing the effect. So if we can use transparent PNG files in a HTML document but we are restricted, It beats not being able to use them at all. Of course, hoping that the restriction will at some point be resolved.

Please do support transparency / real alpha channel for PNG images. Thanks a lot Peter Weustink

Wow. 100 votes.

wow. A bunch of verbose noise in the bug report that doesn't help fix the problem and in fact eats up cycles that could be devoted to the problem. -P

I believe whwat we need to do here is have nsImageFrame create views for images that have more than 1 bit of alpha data in them. The view will need to be set with a flag that tells the view manager that it has translucency (but a different flag from the current one that specifies that the blender should blend every pixel with a single value of opacity). The blender then needs to be able to blend image data in to a drawing surface on a per-pixel basis. There are a few things I am concerned about, such as blending bwtween two drawing surfaces, because on X when we draw in our nsIImage implimentation to a drawing surface, we will loose the alpha data that we would need to blend. I'm not entirely sure how we should go about fixing this, but I'm hoping that someone can help put in some ideas. adding kmcclusk, beard and dcone for view manager and blender ideas.

*** Bug 19283 has been marked as a duplicate of this bug. ***

OK, I am adding the skins and beta 2 keywords here to raise visibility asap. Professional level skins/themes/appearances have been made priority number 1 for beta 2. In order to have decent professional level skins we need alpha channels in PNG in order to: - have controls with bitmap shapes other than rectangular blend smoothly onto a background - have the ability to have gradual drop shadows and hilites GIF does have transparency on a pixel level but you can turn only on or off. Gif only supports 256 colors max which is not sufficient to produce a photorealistic appearance JPEG supports more than 256 colors but is a lossy compression scheme such that the images loose quality significantly. Furthermore no transparency or alpha channels is supported here. In a nutshell: If we want professionally looking stunning skins we oughta have alpha channels in PNG.

Bumping Severity to reflect reality (and to see if the problem with the CC: list truncating is NS 4.x-specific, or also occurs on Mac IE 5.)

Mass-adding beta2 keyword to all skins bugs.

As a point of reference for the URL I referenced in the 1999-07-05 entry above (which includes lots of transparent PNGs, most with RGBA-palettes), I've just added a new page with screen shots here: http://www.cdrom.com/pub/png/pngs-img-ie5mac.html The full-scale versions are 24-bit PNGs, so they'll be a tad slow over a modem. But at least they're interlaced, and the half-scale images embedded in the page are much smaller JPEGs.

Looking at Chris Lilley's "alphatest.png" page, the compositing by Netscape 6 looks pretty terrible. http://www.w3.org/Graphics/PNG/inline-alpha-table http://www.w3.org/Graphics/PNG/inline-alpha.html On the other hand, PNGs with binary transparency, even if carried in the alpha channel, look OK. Here's some code that you can use to help with the alpha compositing problem. It's effect is to cause libpng to return to the application a PNG whose alpha channel has been modified to contain only 0's and 255's, which seem to be rendered properly with NN-6. This code uses the libpng "user transform feature", whereby you only need to supply the transform function and to name it in a call to png_set_user_transform(), which you can put among any other png_set_whatever(). The code is open source freeware. I sent this to Greg the other day, and he remarked that the appearance of the transformed file was quite good, considering the simplicity of the code. I've been using this method of dithering for many years with good success. #if defined(PNG_READ_USER_TRANSFORM_SUPPORTED) /* Put this somewhere ahead of your main program */ * * GlennRP_random_dither_alpha user transform function for libpng * * Dithers the alpha channel down to binary transparency * * Requires rand() function that generates a random number in the range * 0 .. (2^15 -1) * * COPYRIGHT NOTICE, DISCLAIMER, and LICENSE: * * If you modify this file you may insert additional notices after this * sentence. * * The "GlennRP_random_dither_alpha" function is supplied "AS IS". * The author disclaims all warranties, expressed or implied, * including, without limitation, the warranties of merchantability and of * fitness for any purpose. The author assumes no liability for direct, * indirect, incidental, special, exemplary, or consequential damages, which * may result from the use of this function, even if advised of the * possibility of such damage. * * Permission is hereby granted to use, copy, modify, and distribute this * source code, or portions hereof, for any purpose, without fee, subject * to the following restrictions: * * 1. The origin of this source code must not be misrepresented. * * 2. Altered versions must be plainly marked as such and must not * be misrepresented as being the original source. * * 3. This Copyright notice may not be removed or altered from any * source or altered source distribution. * * The Author specifically permits, without fee, and encourages the use of * this source code as a component to supporting the PNG file format in * commercial products. If you use this source code in a product, * acknowledgment is not required but would be appreciated. */ void GlennRP_random_dither_alpha(png_structp png_ptr, png_row_infop row_info, png_bytep data) { png_bytep cp=data+1; if(png_ptr == NULL || row_info == NULL || png_ptr->color_type < 4) return; if(row_info->bit_depth == 8) { int i; if(row_info->color_type == 6) { for (i=0; i<row_info->width; i++,cp+=2) { cp += 2; if (*cp < (rand()>>7)) *cp = 0; else *cp = 255; } } else { for (i=0; i<row_info->width; i++,cp+=2) { if (*cp < (rand()>>7)) *cp = 0; else *cp = 255; } } } else /* bit_depth == 16 */ { int i; cp++; if(row_info->color_type == 6) { for (i=0; i<row_info->width; i++,cp+=4) { cp+=4; if (*cp < (rand()>>7)) { *cp = 0; *(cp+1) = 0; } else { *cp = 255; *(cp+1) = 255; } } } else { for (i=0; i<row_info->width; i++,cp+=4) { if (*cp < (rand()>>7)) { *cp = 0; *(cp+1) = 0; } else { *cp = 255; *(cp+1) = 255; } } } } } #endif /* Put this in your main program after opening your read_ptr, to set * a callback to the GlennRP_random_dither_alpha function after all other * read transforms have been accomplished for a row. */ #if defined(PNG_READ_USER_TRANSFORM_SUPPORTED) # if defined(PNG_READ_EXPAND_SUPPORTED) /* This is required if you want to dither indexed-color PNGS with tRNS */ png_set_read_expand(read_ptr); # endif png_set_read_user_transform_fn(read_ptr, GlennRP_random_dither_alpha); #endif

Bless you, randeg@alum.rpi.edu! for some Real Help. I'll play with your patch today on the major 3 platforms. -P

At Glenn's request, I merged his alpha-dither function with the existing code in ipng.cpp and did some tiny cleanups left over from my ill-fated patch #10; the unified diff is here: http://pobox.com/~newt/test/moz/grr11.dif The same thing with ".txt" appended also works, for those with deficient browsers. (And grr10.dif is still there, too, but it no longer patches cleanly.)

I should have mentioned that the patch (grr11.dif) is untested. I was pretty careful, but one thing I did *not* do was verify that user transforms were supported in libpng 1.0.2, which I believe is what Mozilla still uses.

thanks, GR. I already have it covered. -P

*** Bug 35638 has been marked as a duplicate of this bug. ***

Big Progress: 1> Conversion from 8bit mask to 1bit dithered mask checked in. This is great on platforms that don't support alpha blending. Much thanks to Glenn Randers-Pehrson <randeg@alum.rpi.edu> for the idea and the algorithm. 2> Tim Rowley <tor@cs.brown.edu> contributed blending code for Unix. It works like a champ. Part of this Currently the 8bit conversion to 1bit dithered mask is turned on for all platforms. To test full 8 bit alpha, you can change the ifdef in mozilla/modules/libimg/pngcom/ipng.cpp, line 61, 62 so CAN_SUPPORT_8_BIT_MASK is defined. There are still crashes on window clean up, and resizing of images, so I will leave this turned off for now. ...But feel free to test. Currently, alpha channel looks great on mac ...thanks to Simon <sfraser@netscape.com> and on Unix ...thanks to Tim <tor@cs.brown.edu>. I have some work to do on wintel, to get rid of color banding. -pnunn@netscape.com

I grabbed a sourceball on the evening of 2000-04-14, compiled a completely stock version, and made a few screenshots of the random-dithered alpha transparency (mainly for developers of other browsers to see): http://www.cdrom.com/pub/png/pngs-img-moz-dith.html It's pretty good, though not in the same league as MSIE 5.0 for Mac. But then I defined CAN_SUPPORT_8_BIT_MASK in ipng.cpp, recompiled libnspng.so, and fired it up: http://www.cdrom.com/pub/png/pngs-img-moz.html It's gorgeous! Aside from the interlacing bug (bug 3195), it's the equal of MacIE 5.0. Well done, Tim and Pam! It's truly a lovely thing to behold. I look forward to seeing this bug closed out at last. I do have one small patch to fix a minor bit of nonsense near line 300: *** ipng.cpp.stock Thu Apr 13 12:47:18 2000 --- ipng.cpp Sat Apr 15 13:45:51 2000 *************** *** 291,301 **** ipng_p->alpharow = NULL; #if defined(CAN_SUPPORT_8_BIT_MASK) ! if(png_ptr->color_type || PNG_COLOR_MASK_ALPHA ) ! ic->image->header.alpha_bits = 8/*png_ptr->pixel_depth*/; /* 8 */ ! else #endif - ic->image->header.alpha_bits = 1; ic->image->header.alpha_shift = 0; ic->image->header.is_interleaved_alpha = TRUE; } --- 294,303 ---- ipng_p->alpharow = NULL; #if defined(CAN_SUPPORT_8_BIT_MASK) ! ic->image->header.alpha_bits = 8; ! #else ! ic->image->header.alpha_bits = 1; #endif ic->image->header.alpha_shift = 0; ic->image->header.is_interleaved_alpha = TRUE; } Greg

Forgot to mention that I opened a related performance bug: bug 36002. This has to do with the large disparity between scrolling opaque images and scrolling alpha-transparency ones (which sets it apart from bug 26502). I don't believe this is directly related to ImageLib--it seems to cut across layout (which should know whether there are any dynamic elements on the page), the compositor (which is probably where the main fix would go), and gfx+libimg (which is the source of the alpha-compositing code that gets called far too often).

Enabled 8 bit mask generation on all platforms. If you find a bug, please create a new bug report for it and don't reopen this one. This bug has been drowned in verbage and has been less effective in communicating technical details. thanks, pnunn

Rubber-stamping as "verified that functionality is implemented cross-platform". So, if anyone would like to identify and report new bug reports containing any holes in the PNG transparency implementation, please feel empowered to do so. (we know Binary transparency doesn't work, 19283)

8-bit transparency doesn't work on Windows, either. See bug 36694.

Please be the first ones to fully support the PNG transparency. I think it would really be a big point to brag about, and we could all start creating much better looking graphics/effects.