User Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 Build ID: 20110908135051 Steps to reproduce: I want to load a RGBA BMP image into a WebGL texture. The texture is for a tree model. The RGB channel of the texture stored color map and the alpha channel of which stored the opacity map of the tree leaves. Actual results: Everything works fine in chrome, but in firefox, I found that only RGB parts of the image were loaded into the texture, however, the alpha channel is always 1.0 no matter what the value is in the image. Expected results: The alpha value of the image should enable WebGL performs alpha testing when rendering the tree model.

Brian tells me that it's worth trying Firefox 9 (Nightly) as this might have changed. Also notice that the BMP file format is obsolete and if you have a choice, it's better to use PNG.

I confirm that the texture is working fine in Firefox 9 :-) Notice that to allow using local files as textures you need to go to about:config and set security.fileuri.strict_origin_policy to false. Only do this in a test profile, as this is a security vulnerability.

oops. No, not fixed in Firefox 9, sorry. The texture is indeed rendered as fully opaque in Firefox 9 while it is transparent in Chrome 13.

Support was actually added in Firefox 9 for transparent bitmaps, but we only enable it currently for bitmaps loaded inside an icon file. I did this only to keep everything the same as it used to be and not cause new regressions. This shouldn't be too hard to enable. I want to test it, and verify if we should only enable it for certain bitmap headers, but all we should have to do is default mUseAlphaData to true in the BMP decoder. http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/decoders/nsBMPDecoder.cpp#76

We are working on Oak3D project which is an free WebGL based javascript framwork. So we can not put certain limitation on what kind of image the developers should use, indeed, this often depends on artist who creating the art asset. And opacity map I think is often used in real-time rendering when simulate plants,railings and so on, so I hope this can be fixed in the near future:) Thank you very much!

For a 40 byte file headers, the BMP spec says that the 4th byte should be reserved and always 0. The BMP file format does not specify what should happen when this value is not 0. The ICO file format though specifies that the 4th byte can be used for transparency (if not all 0) when a BMP is stored. Programs that use the 4th byte for alpha data: Google Chrome, and GIMP Programs that do not use the 4th byte: Firefox all versions, IE, Windows, Photoshop I don't see any harm in supporting this for BMP files though. Supporting it is only 1 line of code because the code is already there for handling of ICO files that use the transparency byte for each quad.

By the way, BMPs with BITMAPV3INFOHEADER and above support transparency properly but I don't know of any program that generate them. The bitmap in this bug report falls into the case of a 40 byte file header which is for BITMAPINFOHEADER and is using the 4th byte as alpha (as if it were a BMP inside of an ICO).

Confirmed that the WebGL texture works now in the demo. We support RGBA BMPs the same as Google Chrome and GIMP with this patch. We did not support RGBA BMPs ever before this patch though.

Comment on attachment 560827 [details] [diff] [review] Patch for adding RGBA BMP support Review of attachment 560827 [details] [diff] [review]: ----------------------------------------------------------------- I think you should just remove mUseAlphaData, since now it's only ever set to true.

ok will do.

Pushed to try: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=574c6321fef4

What happened after pushing to try?

Sorry not sure what happened on this one, I think this patch should be redone/updated though after bug 722555 lands.

Bug 722555 was landed far back. Is this bug forgotten again?

Note this is not a regression from bug 722555. It is not forgotten it's just was never a priority for me in comparison to other things. If you want this fixed please try to find another owner.

No assignee, updating the status.