On Sat, Jan 2, 2016 at 12:41 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-01-01 um 18:15 schrieb Aaryaman Vasishta:
expected = (info_header.biWidth + 3) & ~3;ok(expected == img->bytes_per_line, "Expected bytes per line ==%d, got %d.\n", expected, img->bytes_per_line);
if (depth == 8){for (i = 0; i < h; i++){offset = upside_down ? (img->bytes_per_line * (h - i -1)) : (img->bytes_per_line * i);
for (j = 0; j < img->bytes_per_line; j++){if (buffer1[k++] != buffer2[offset++])return FALSE;}You want j < img->width here, otherwise you compare the padded bytes against the next line of the input image. (You'll then also compare the follow-up lines incorrectly and read past the input buffer). It works here because you pass an image with a width that's a multiple of 4 when this codepath is used.
So iterate over width pixels, but advance the read offset / pointer by bytes_per_line bytes after processing one line.
It seems for any 8bpp image loaded by d3drm, the bytes_per_line is always == width regardless of whether the width is a multiple of 4 or not. So there's essentially no padding between lines. Hence, using bytes_per_line instead of width here doesn't really make a difference.
I've sent a try 7 with the other changes we discussed on IRC, but if you want me to change this to use img->width instead of bytes_per_line I don't mind that either.