[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-08 09:23:03.000000000 -0400
+++ shadow/79246.tmp.17875	2006-09-08 19:25:09.000000000 -0400
@@ -324,6 +324,22 @@
   (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.
+
+------- Additional Comments From 4lw0e0402 at sneakemail.com  2006-09-08 19:25 -------
+I believe the tests should be reworked, and further, that LockBits 
+need not actually be used. There are separate tests for LockBits in 
+the System.Drawing/Test/System.Drawing subdir, and these tests are 
+intended only to determine whether the codec actually loaded the 
+correct pixels. There's no reason why Bitmap.GetPixel() should not be 
+used, in which case the stride is a non-issue (or rather, an issue 
+that is handled entirely in the underlying well-tested (hopefully) 
+libgdiplus code).
+
+Should I go ahead and redo the test cases that have the stride 
+assumption flaw in them to use a pseudo-random number generator with 
+a different seed for each test (so that different pixels are loaded)? 
+If so, then I'll put correct images in place for each test at the 
+same time.