[PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

[Martin Storsjö]

On Wed, 12 Feb 2014, Stefan Dösinger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 2014-02-11 12:14, schrieb Martin Storsjo:
>> +        hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL);
>> +        ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr);
> Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code.

Indeed, I changed the texture size later yesterday (and removed the 
hardcoded numbers by making the width/height a local variable); will check 
that capability.

> There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this.

Yeah, it's probably not worth worrying about that case.

>> +            memset(&lr, 0, sizeof(lr));
>> +            hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0);
>> +            ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr);
> There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds.

Ok - this was an artifact from the existing yuv_color test FWIW.

>> +            /* Draw the top left quarter of the screen with color1, the rest with color2 */
>> +            for (y = 0; y < 8; y++)
>> +            {
>> +                for (x = 0; x < 8; x += 2)
>> +                {
>> +                    DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2;
>> +                    BYTE Y = (color >> 16) & 0xff;
> It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on.

I guess it would make things a little bit more difficult when the output 
is filtered. As long as we calculate how to hit the center of the pixels 
correctly I guess it should work, but I went the easy route and just draw 
the top-left quarter of the screen in one color and the rest in another, 
and sample at four points near the corners of each quadrant.

Handling the individual two different Y values in UYVY/YUY2 is already 
tested in the yuv_color test anyway, and for the other pixel formats there 
isn't really any distinction between first/second Y samples.

I'll fix up the other style issues you pointed out and resend the set 
later today then.

// Martin