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.