[Mono-osx] Bug in Drawing.Bitmap.LockBits function?

[Pedro Gutierrez]

Hi,

I'm trying to run some OpenGL samples on my MacBook Pro (CD), with  
mono 1.2.3.1, Tao Framework (2.0 RC1) and cocoa-sharp. The only  
problem, so far, has been within the code for loading a bitmap as a  
texture. I created a 256x256 bitmap with an uniform background color  
(RGB values = 33, 66, 99), but it does not load correctly. The  
problem is the array of bytes returned by the LockBits function. See  
the sample code:

// load the bmp
Drawing.Bitmap bitmap = new Drawing.Bitmap ("oneColor.bmp");
// test that the bmp has been loaded correctly
for (int i = 0; i < 10; ++i) {
	Drawing.Color pixelColor = bitmap.GetPixel (i, 0);
	Console.WriteLine ("RGB = {0} {1} {2} " , pixelColor.R,  
pixelColor.G, pixelColor.B);
}
// so far so good, it prints the correct RGB values for 10 pixels  
(have tested it with the whole bitmap)

// to load a bitmap as a texture I need an IntPtr to the bytes, so a  
BitmapData object must be created
Drawing.Rectangle rect = new Drawing.Rectangle (0, 0, bitmap.Width -  
1, bitmap.Height - 1); // a Rect with the bitmap dimensions is needed
// lock bits for read-only operations with a specific format RGB, 24  
bits no alpha
Drawing.Imaging.BitmapData bdata;
bdata = bitmap.LockBits(rect, Drawing.Imaging.ImageLockMode.ReadOnly,  
Drawing.Imaging.PixelFormat.Format24bppRgb);
// test the first 150 locked bytes
for (int i = 0; i < 150; ++i)
	Console.Write (Marshal.ReadByte (bdata.Scan0, i).ToString () + ", ");

The result is (formatted to show that a pattern exists):
99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,

99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,

99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,33,255,
99,255,66,33,255,255,
99,66,33,255,255,
99,66,255,

I know that BMP files store BGR instead of RGB values, but this  
values do not make sense. I also tried with  
PixelFormat.Format32bppRgb and PixelFormat.Format32bppArgb, a  
slightly different pattern is printed, but it does have those 255  
values all over the place.

Am I doing something wrong or is it a bug?

I can work around this "bug" with cocoa-sharp: creating a  
NSBitmapImageRep and reading its bitmapData property, which returns  
the correct values.

Regards,

Pedro



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20070320/e72bf361/attachment.html