230636 - Download Manager doesn't support alpha (transparency) channel for icons

Status: RESOLVED FIXED

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

Description

[Petey]

The new "Download System Upgrade II" for the .8 release is nifty, but it does
not support the alpha channel of those icons that have them. A good example is
the .zip icon that comes with WinZip: The icon has a solid black drop-shadow
effect to it instead of the soft alpha-blended shadow that it should have.

I don't know the technical issues of including an alpha channel, or if it is
even possible with XUL, but it would certainly make for a more aesthetically
pleasing effect.

Comment 1

[Oleg Sidletskiy]

Attachment: an example

Comment 2

[Oleg Sidletskiy]

-> a better summary

Comment 3

[[e-mail]]

Mine.

Comment 4

[[e-mail]]

Attachment: Proposed patch

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 141776 [details] [diff] [review]
Proposed patch

   PRUint32 bpr;
   mFrame->GetAlphaBytesPerRow(&bpr);
hm, this is confusingly named... maybe abpr would be better... well, this is
not code you changed, feel free to leave as-is

I wonder if it would be better to do the A1->A8 conversion in ProcessData
instead... probably makes no difference.

you can remove the GFXFORMATALPHA define now, right?


don't bother with the change in nsICODecoder::Close... nobody will reuse a
decoder anyway



-	 PRUint32 colorSize = (((maskInfo.bmiHeader.biWidth + 1) * 3) & ~3) *
maskInfo.bmiHeader.biHeight;
+	 PRUint32 colorSize = maskInfo.bmiHeader.biWidth *
maskInfo.bmiHeader.biHeight * 4;

can you explain this change?
a bit more context would also be nice...


r=me with the removal of the change in ::Close and explanation of
nsIconChannel.

Comment 6

[[e-mail]]

Attachment: Addressed review comments

Changing the bpp from 24 to 32 means that image rows are automagically dword
aligned thus substantially simplifying the calculation for the image size.

Comment 7

[[e-mail]]

Comment on attachment 142385 [details] [diff] [review]
Addressed review comments

This should have be useful for mail attachment icons too.

Comment 8

[[e-mail]]

Fix checked in.

Comment 9

[Scott MacGregor]

Neil, I'm getting a lot of reports from thunderbird testers that are no longer
getting attachment icons to show up anymore after giving them a build that has
this checkin to our icon code. Some icons do render correctly but others like
winzip and PDF are not. I"m asking for more information such as color bit,
resolution, etc. Will post back with that info. 

Comment 10

[[e-mail]]

Another step they can try is to open moz-icon://.zip?size=16 and see if anything
appears and if they can save it to disk as zip.ico and see if the saved file
displays in explorer.

If I am correct this is the case that I was trying to fix, i.e. those icons were
supposed to (but did not) have alpha transparency and now somehow they have all
transparancy :-(

Comment 11

[[e-mail]]

... of course they have to use a recent ff/seamonkey for the above test...

Comment 12

[Scott MacGregor]

Some background info:

Win2k SP4, 1024x768, 24bit color 

I'll ask one of them to try saving a moz-icon to disk

Comment 13

[José Jeria]

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