Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).

[Stefan Dösinger]

-----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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWhs9jAAoJEN0/YqbEcdMwx6kP/RXJJdivWRU1ouvEP32VWNRA
O/tOZxGNJnXw0Rz40QQz1rtckN3GGAe54pwilQbaPAqrZeIDAEWfk4gWMKIvHvUw
Vdg3w7dfQv6fpKK16EWWb83gdaQU9X3Nc7bFzHx4XwvkjHgV/ztsk/t6cqkAOv2Y
cWul6MpQcWvehGyEv+vk1siMxO5zFjLvBpT7jgFh+7Ehzbk8ziZWdBYGjV18PnAQ
4eT5MrsNbaA99wKj7ibhz9I4GsKLf8oQQAFFqcVTutCOLeQh7zvHkQ4Z4glXSEYu
VvNRmLdMYNSYho+Z9lZEABNvaw9lkxJ6/r1OYd3tP2A0TZzKur732iUYwTo1RnFB
Hlv6K/PKzTTMN1m9GZ8UiltnjsEq5G+05nkaywsh7pkr9bGU2pfSEihZ8BSX1/4a
zG+vLJipg/rdHalQKfCflxWpKcHiIFjm5E/+Bdtgzb3sSksPh2bfmdVDW/bl3lvD
OMXD2FgHB4BE+lexisBV7+qlQhlv8vEPgWryoJ8xomfyAc0ZHioOgTrq0XSMrTdC
19oNGDWZd/8P1guTTC3eRlBFA3jYt/yvjzINRYG1h9L5DbYISuMbp0oUSFx3412o
YB7HTHjbyxcWhZFEXc9oDHoMzfIEyJI1QOa8fCNkisucCc/idN7Zrqz+3wYJhHCu
PjleVblBVMqsSN/Qw2OE
=ftwX
-----END PGP SIGNATURE-----

[PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).

[Aaryaman Vasishta]

On Sat, Jan 2, 2016 at 12:41 AM, Stefan Dösinger <stefandoesinger(a)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.