[Mono-bugs] [Bug 79246][Nor] Changed - Bitmap.LockBits doesn't behave like MS

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by 4lw0e0402 at sneakemail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=79246

--- shadow/79246	2006-09-01 10:55:20.000000000 -0400
+++ shadow/79246.tmp.5043	2006-09-05 01:45:55.000000000 -0400
@@ -2,16 +2,16 @@
 Product: Mono: Class Libraries
 Version: 1.1
 OS: All
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: libgdiplus
-AssignedTo: peter at novonyx.com                            
+AssignedTo: 4lw0e0402 at sneakemail.com                            
 ReportedBy: sebastien at ximian.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
 Summary: Bitmap.LockBits doesn't behave like MS 
@@ -30,6 +30,48 @@
 
 How often does this happen? 
 *always
 
 Additional Information:
 * this happens for every codec (see unit tests)
+
+------- Additional Comments From 4lw0e0402 at sneakemail.com  2006-09-05 01:45 -------
+I took a look at the test cases for the BMP codec, and noted the 
+following things:
+
+1. The "almogaver1bit.bmp" file is actually a 4-bit BMP file. This is 
+most evident when opening the file in a viewer: It actually has 
+colours! The test for this seems to express confusion over why a 1-
+bit BMP file would result in a 4-bit PixelFormat. Well, the reason is 
+that it's not a 1-bit BMP file! :-)
+
+2. The Bitmap24bitData() test is inherently broken because it assumes 
+that all implementations of a BMP codec will return the same in-
+memory stride. This is clearly not the case; the only rule, apart 
+from that it be wide enough for all the bits in each row, is that the 
+stride be a multiple of 4 bytes. The test jumps forward randomly by 
+1009 bytes and ends up with a different (x, y) coordinate depending 
+on the stride of the bitmap data, which differs between MS 
+GDIPLUS.DLL and libgdiplus.
+
+3. The Bitmap32bitData() test seems to have uncovered a possible bug 
+in Microsoft's BMP loader, or else a misinterpretation in our 
+bmpcodec.c of the 32-bit data. Unless the alpha is inverted, so that 
+its interpretation is as how transparent the pixel should be rather 
+than how opaque it should be, every pixel in that bitmap should be 
+completely transparent. Look at the file in a hex editor and it's 
+quite plain: the 4th byte of every quad is 00h, not FFh.
+
+So, to summarize, the fact that Bitmap.GetPixel() within than test 
+returns pixels with an alpha of FFh means one of three things: a) MS 
+GDIPLUS.DLL has a bug in it, b) BMP files store tranparency values 
+instead of opacity values, or c) MS GDIPLUS.DLL simply calls into the 
+underlying GDI32 code for loading bitmaps, which has no support 
+whatsoever for translucency.
+
+Unless b) is the case, I put forth that we should continue to "do the 
+right thing" here, because I doubt anybody will actually want alpha 
+forced to 255 in BMP files (and if they do and they complain about 
+it, we can change it then).
+
+I have yet to look at the other System.Drawing.Imaging test cases 
+marked [NotWorking].