124519 - Icon backgrounds are non-transparent

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[hacker formerly known as [e-mail]]

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

[Daniel Switkin]

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?

Comment 2

[Paul]

Well, I was going to look into this tonight, but someone just broke the tree!

Comment 3

[Paul]

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.

Comment 4

[Paul]

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

[Daniel Switkin]

Is this broken on other platforms? It was working in the 0.9.8 milestone.

Comment 6

[hacker formerly known as [e-mail]]

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

[Daniel Switkin]

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.

Comment 8

[Paul]

Attachment: Patch according to Daniel's comments

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

Comment 9

[Daniel Switkin]

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=[e-mail]

Comment 10

[hacker formerly known as [e-mail]]

Yep, that patch fixes the problem for me.  Thanks guys.

Comment 11

[Paul]

The above patch has been checked in.  Marking fixed.

Comment 12

[hacker formerly known as [e-mail]]

Verified.