[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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160102/9d061603/attachment.html>