Last Comment Bug 3013 - [skins] PNG [alpha] transparency not supported
: [skins] PNG [alpha] transparency not supported
Status: VERIFIED FIXED
alpha still not supported correctly ....
:
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All All
: P2 normal with 58 votes (vote)
: ---
Assigned To: pnunn
: Eli Goldberg
Mentors:
http://www.w3.org/Graphics/PNG/inline...
: 2587 14926 19538 19539 26894 35638 (view as bug list)
Depends on:
Blocks: 29160
  Show dependency treegraph
 
Reported: 1999-02-08 10:30 PST by David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
Modified: 2009-01-22 10:17 PST (History)
21 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
A red to transparent ramp. Easy way to check alpha support. (2.82 KB, image/png)
1999-10-08 23:16 PDT, Keith Rarick
no flags Details
image for simple testcase (817 bytes, image/png)
1999-11-01 10:30 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details
HTML for simple testcase, using attached image (709 bytes, text/html)
1999-11-01 10:32 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details
Demonstrates incorrect compositing in Mozilla up to M13 (150 bytes, text/html)
2000-03-02 08:27 PST, chris
no flags Details

Description David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-02-08 10:30:53 PST
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.
Comment 1 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-02-08 10:36:59 PST
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
Comment 2 bkdelong 1999-02-08 10:51:59 PST
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
Comment 4 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-02-20 13:10:59 PST
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.)
Comment 5 michaelp 1999-04-07 14:48:59 PDT
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.
Comment 6 Greg Roelofs 1999-07-05 17:16:59 PDT
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.
Comment 7 Greg Roelofs 1999-07-12 07:18:59 PDT
The PNG icon at the URL above is now fixed, and Mozilla displays it identically
to the GIF.
Comment 8 dcone (gone) 1999-09-01 12:43:59 PDT
The PNG's have transparency..
Comment 9 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-09-01 12:52:59 PDT
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?
Comment 10 dcone (gone) 1999-09-01 13:48:59 PDT
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.
Comment 11 Greg Roelofs 1999-09-01 13:57:59 PDT
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
Comment 12 dcone (gone) 1999-09-01 14:07:59 PDT
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.
Comment 13 pnunn 1999-09-01 14:34:59 PDT
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
Comment 14 Greg Roelofs 1999-09-01 17:26:59 PDT
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?
Comment 15 pnunn 1999-09-02 10:27:59 PDT
Thresholded alpha is NOT A BUG. It may be an
implementation you dont like, but it is not a
bug.
-p
Comment 16 Eli Goldberg 1999-09-02 10:43:59 PDT
"It's not a bug, it's a feature!"

Thus, re-opening as a feature request, for after Pam has finished more critical
functionality.
Comment 17 Eli Goldberg 1999-09-02 10:45:59 PDT
[Re-opened as RFE, M20.]
Comment 18 Greg Roelofs 1999-09-02 12:05:59 PDT
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.
Comment 19 pnunn 1999-09-02 12:41:59 PDT
Its a pleasure to work with you, Greg.
-p
Comment 20 Greg Roelofs 1999-09-03 06:41:59 PDT
Apologies to all for the unnecessarily strong language.  (Private message sent
to Pam.)

Greg
Comment 21 pnunn 1999-09-10 10:38:59 PDT
*** Bug 2587 has been marked as a duplicate of this bug. ***
Comment 22 Sjoerd Visscher 1999-09-17 14:51:59 PDT
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)
Comment 23 Eli Goldberg 1999-09-27 11:18:59 PDT
*** Bug 14926 has been marked as a duplicate of this bug. ***
Comment 24 Keith Rarick 1999-10-08 23:16:59 PDT
Created attachment 2050 [details]
A red to transparent ramp. Easy way to check alpha support.
Comment 25 Matthew Thomas, usability weenie 1999-10-31 18:08:59 PST
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
Comment 26 Michael T. Babcock 1999-10-31 20:48:59 PST
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).
Comment 27 ssym 1999-10-31 21:04:59 PST
...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.
Comment 28 Michael Lowe 1999-10-31 21:59:59 PST
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?
Comment 29 Matthew Thomas, usability weenie 1999-10-31 23:40:59 PST
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
Comment 30 Greg Roelofs 1999-11-01 08:00:59 PST
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
Comment 31 Eli Goldberg 1999-11-01 10:09:59 PST
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!
Comment 32 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-11-01 10:30:59 PST
Created attachment 2526 [details]
image for simple testcase
Comment 33 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-11-01 10:32:59 PST
Created attachment 2527 [details]
HTML for simple testcase, using attached image
Comment 34 Stuart Parmenter 1999-11-01 11:49:59 PST
are you volunteering to write some compositing code for linux us to use on
linux?
Comment 35 Simon Fraser 1999-11-01 11:57:59 PST
FWIW, I implemented code in nsImageMac.cpp to do 8-bit alpha blending on Mac.
This is not checked in yet.
Comment 36 Ian Clark 1999-11-01 13:37:59 PST
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.
Comment 37 Greg Roelofs 1999-11-01 19:02:59 PST
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
Comment 38 chris 1999-11-12 00:49:59 PST
Another testcase: http://www.w3.org/Graphics/PNG/inline-alpha-table to test
compositing against different backgrounds
Comment 39 chris 1999-11-12 00:56:59 PST
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.
Comment 40 Eli Goldberg 1999-11-18 15:15:59 PST
*** Bug 19283 has been marked as a duplicate of this bug. ***
Comment 41 Greg Roelofs 1999-11-23 07:24:59 PST
*** Bug 19539 has been marked as a duplicate of this bug. ***
Comment 42 Greg Roelofs 1999-11-23 07:29:59 PST
*** Bug 19538 has been marked as a duplicate of this bug. ***
Comment 43 Greg Roelofs 1999-11-23 07:38:59 PST
*** Bug 19538 has been marked as a duplicate of this bug. ***
Comment 44 tor 1999-12-17 15:08:59 PST
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?
Comment 45 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-12-17 15:50:59 PST
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).
Comment 46 Eli Goldberg 2000-01-28 10:37:58 PST
Per e-mail from Greg, he has relinquished PNG component ownership; thus, 
reassigning assigned bugs to ImageLib owner.
Comment 47 Gervase Markham [:gerv] 2000-02-07 16:15:02 PST
*** Bug 26894 has been marked as a duplicate of this bug. ***
Comment 48 Stuart Ballard 2000-02-21 13:21:28 PST
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.
Comment 49 styles 2000-03-01 09:26:03 PST
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
Comment 50 Eli Goldberg 2000-03-01 09:32:06 PST
styles@ergonet.com: So, are you volunteering to write the code...?
Comment 51 jlarsen 2000-03-01 09:40:56 PST
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 :)
Comment 52 styles 2000-03-01 10:01:48 PST
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.
Comment 53 styles 2000-03-01 11:13:31 PST
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.
Comment 54 Matthew Tuck [:CodeMachine] 2000-03-01 14:32:15 PST
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.
Comment 55 Eli Goldberg 2000-03-01 14:38:27 PST
matty@box.net.au: So, are _you_ volunteering to write the code...? ;)
Comment 56 peter 2000-03-01 17:55:06 PST
Is there some documentation available as to where one should poke?
Comment 57 Matthew Paul Thomas 2000-03-01 18:36:12 PST
Yes, see Greg's page <http://www.cdrom.com/pub/png/pngmoz.html>.
Comment 58 Greg Roelofs 2000-03-01 18:43:09 PST
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.
Comment 59 tor 2000-03-01 22:47:57 PST
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.
Comment 60 Greg Roelofs 2000-03-02 07:28:21 PST
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
Comment 61 chris 2000-03-02 08:27:47 PST
Created attachment 5985 [details]
Demonstrates incorrect compositing in Mozilla up to M13
Comment 62 tor 2000-03-02 09:05:05 PST
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.
Comment 63 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-03-02 09:26:18 PST
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.)
Comment 64 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-03-02 09:59:20 PST
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...
Comment 65 pnunn 2000-03-02 10:15:27 PST
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
Comment 66 styles 2000-03-02 11:54:43 PST
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.
Comment 67 salabim 2000-03-03 07:02:19 PST
Please do support transparency / real alpha channel for PNG images.

Thanks a lot

Peter Weustink

Comment 68 Jesse Ruderman 2000-03-05 23:56:37 PST
Wow. 100 votes.
Comment 69 pnunn 2000-03-06 09:52:28 PST
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
Comment 70 Stuart Parmenter 2000-03-14 17:11:12 PST
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.
Comment 71 dcone (gone) 2000-03-14 18:29:32 PST
*** Bug 19283 has been marked as a duplicate of this bug. ***
Comment 72 german 2000-04-06 09:49:16 PDT
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.
Comment 73 Eli Goldberg 2000-04-06 10:10:05 PDT
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.)
Comment 74 Peter Trudelle 2000-04-06 16:48:12 PDT
Mass-adding beta2 keyword to all skins bugs.
Comment 75 Greg Roelofs 2000-04-09 18:38:54 PDT
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.
Comment 76 Glenn Randers-Pehrson 2000-04-09 20:23:57 PDT
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

Comment 77 pnunn 2000-04-10 11:14:11 PDT
Bless you, randeg@alum.rpi.edu! for some Real Help.
I'll play with your patch today on the major 3 platforms.

-P
Comment 78 Greg Roelofs 2000-04-10 23:29:00 PDT
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.)
Comment 79 Greg Roelofs 2000-04-10 23:41:10 PDT
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.
Comment 80 pnunn 2000-04-11 10:26:19 PDT
thanks, GR. I already have it covered.
-P
Comment 81 pnunn 2000-04-12 13:57:34 PDT
*** Bug 35638 has been marked as a duplicate of this bug. ***
Comment 82 pnunn 2000-04-13 17:30:42 PDT
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
Comment 83 Greg Roelofs 2000-04-16 15:48:13 PDT
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
Comment 84 Greg Roelofs 2000-04-16 17:30:03 PDT
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).
Comment 85 pnunn 2000-04-20 15:46:38 PDT
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
Comment 86 Eli Goldberg 2000-04-24 15:46:01 PDT
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)
Comment 87 Greg Roelofs 2000-04-25 07:50:07 PDT
8-bit transparency doesn't work on Windows, either.  See bug 36694.
Comment 88 brad.mosch 2000-05-30 13:06:42 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.