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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
