[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 sebastien at ximian.com.

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

--- shadow/79246	2006-09-08 00:47:06.000000000 -0400
+++ shadow/79246.tmp.6494	2006-09-08 09:23:03.000000000 -0400
@@ -301,6 +301,29 @@
 }
 
 This particular approach would end up comparing roughly (Height * 2) 
 of the pixels in the bitmap. Adjust the upper bound of the r.Next() 
 call in the middle of the loop to compare greater or fewer pixels.
 
+
+------- Additional Comments From sebastien at ximian.com  2006-09-08 09:23 -------
+[1] my original comment stays: this must be fixed with "correct
+images" in all cases
+
+[2] thanks for the long explanation. I had it right, however IMO not
+computing the Stride like MS is a BUG(*). The test case was build form
+code received from someone(**), so this behaviour is important to
+existing code. As a matter of fact we already have similar tests using
+GetPixel.
+
+(*) We're fixing difference *a lot* smaller than this. Now I'm not
+saying this is "the top" priority bug inside libgdiplus but it is one
+nevertheless. So let's 
+   (a) keep the tests as [NotWorking], add an Assert to compare the
+Stride values and a comment 
+- or -
+  (b) rework the tests to get random pixels on each lines *and*
+respect the Stride (and add a comment about that).
+We can also open a separate bug about "codec versus stride compatibility".
+
+(**) and it exposed a bug where all the frist two lines of our JPEG
+images had a corrupted byte for each pixel.