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