Closed Bug 230636 Opened 21 years ago Closed 20 years ago

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

Categories

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

x86
Windows XP
enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: lunchtimemama, Assigned: neil)

References

Details

(Keywords: polish)

Attachments

(2 files, 1 obsolete file)

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.
Attached image an example
-> a better summary
Summary: Download Manager supporting XP icons → Download Manager doesn't support alpha (transparency) channel for icons
Priority: -- → P3
Target Milestone: --- → Firebird1.0
Keywords: polish
Mine.
Assignee: bugs → neil.parkwaycc.co.uk
Component: Downloading → ImageLib
Product: Firefox → Browser
Target Milestone: Firefox1.0 → ---
Version: unspecified → Trunk
Attached patch Proposed patch (obsolete) — Splinter Review
Attachment #141776 - Flags: review?(cbiesinger)
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.
Attachment #141776 - Flags: review?(cbiesinger) → review+
Changing the bpp from 24 to 32 means that image rows are automagically dword
aligned thus substantially simplifying the calculation for the image size.
Attachment #141776 - Attachment is obsolete: true
Attachment #142385 - Flags: review?(cbiesinger)
Attachment #142385 - Flags: review?(cbiesinger) → review+
Comment on attachment 142385 [details] [diff] [review]
Addressed review comments

This should have be useful for mail attachment icons too.
Attachment #142385 - Flags: superreview?(mscott)
Attachment #142385 - Flags: superreview?(mscott) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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. 

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 :-(
... of course they have to use a recent ff/seamonkey for the above test...
Some background info:

Win2k SP4, 1024x768, 24bit color 

I'll ask one of them to try saving a moz-icon to disk
*** Bug 238503 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: