Icon backgrounds are non-transparent

VERIFIED FIXED

Status

()

Core
ImageLib
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: hacker formerly known as seawood@netscape.com, Assigned: Paul)

Tracking

Trunk
Other
BeOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

I just updated my local BeOS build for the first time in a week so I'm not sure
when this problem occurred.  Just about every icon is showing a black background
where it should be transparent.  It is very noticeable in the personal toolbar
(especially if you have bookmarks with site icons) and in the mailnews window. 
 The one exception seems to be the mozilla.org icon.  It has a white background
but it still doesn't match the skin.  I'm using the modern theme, if it matters.

Comment 1

17 years ago
Chris, can you verify whether your build is before or after the patch for 122121 was 
checked in? Also, what bit depth are you running the graphic card at?
(Assignee)

Comment 2

17 years ago
Well, I was going to look into this tonight, but someone just broke the tree!
(Assignee)

Comment 3

17 years ago
Scratch that, mathml is now "enabled" by default.  It declares new functions in
the DeviceContext, that did not exist before.  I will file a new bug.
(Assignee)

Comment 4

17 years ago
Ok, I created a transparent image, saved as gif and png, and put on a test
page.  Transparency did not work for either image.  Just to test the images, I
brought the page up in Net+, and it was as it should be.  Oh, and as for the
mozilla icon have a white background, while the rest are black.  The mozilla
icon is a PNG, while the others are GIFs.  The same thing happened in my test,
the GIF had a black background, the PNG had a white.
At least it's consistent :)
My last update off of the trunk was right before the 0.9.8 release, when I was
trying to get the BONE patch finished, so this was introduced some time 
between now and the week of the 0.9.8 release.

Comment 5

17 years ago
Is this broken on other platforms? It was working in the 0.9.8 milestone.
Daniel, my build was after the new gfx checkin which is why I cc'd you on this
bug just in case.  I started pulling at around 1pm PST 2002-02-08. 16bpp
display.  I don't see the problem on Linux nor w2k.

Comment 7

17 years ago
I was just staring off into space and I figured out what happened.

In the big gfx change I implemented Optimize() for the first time, but no one was calling 
it. Recently, bug 104999 was checked in. When they call Optimize(), and the image has 
alpha, I'm deleting the mAlphaBits data. Subsequently, there are three places which need to 
know whether to draw in B_OP_ALPHA or not (this is all in nsImageBeOS.cpp). Currently they 
are testing (nsnull != mAlphaBits). This should be changed to (0 != mAlphaDepth), since 
this variable is not reset in Optimize().

Since I'm not sync'ed up, Paul please make the change and I'll approve the patch.
(Assignee)

Comment 8

17 years ago
Created attachment 68759 [details] [diff] [review]
Patch according to Daniel's comments

Daniel, yo da man!
Chris, can you test this to verify?

Comment 9

17 years ago
If I was more da man I wouldn't have written this bug in the first place. :) But in my 
defense Optimize() wasn't being called so I couldn't test it properly...

r=mozilla@switkin.com
Yep, that patch fixes the problem for me.  Thanks guys.
(Assignee)

Comment 11

17 years ago
The above patch has been checked in.  Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.