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.