[PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)

[Matteo Bruni]

2014-05-14 17:06 GMT+02:00 Henri Verbeet <hverbeet at gmail.com>:
> On 14 May 2014 16:12, Matteo Bruni <mbruni at codeweavers.com> wrote:
>> ---
>>  dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 107 insertions(+), 26 deletions(-)
>>
> Unfortunately this still fails for me on Windows. The returned counts
> change between runs, which could perhaps be related to the backbuffer
> size being larger than the window size. It does seem to reliably pass
> when either running the test in fullscreen mode, or changing the
> backbuffer size to e.g. 640x480. The former is probably the easier
> fix.
>

Okay, going for fullscreen.

>> +    ok(data.word[0] == (WORD)expected || broken(!data.word[0]),
>> +            "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]);
>> +    if (!data.word[0])
>> +    {
>> +        skip("Occlusion query result looks broken, ignoring returned count.\n");
>> +        broken_occlusion = TRUE;
>> +    }
> At 1024x768 for example, "expected" is going to be 0xc0000. Is this
> for drivers that always return 0 for occlusion queries, or is this for
> the testbot, which IIRC runs at the resolution? If it's really broken,
> I think this should also check for "(WORD)expected" being 0, and then
> use win_skip() instead of skip().

It's for the testbot, which AFAICS returns 0 regardless of the
resolution or fullscreen / windowed mode. I haven't seen other D3D
drivers claiming to support occlusion queries and then returning 0
yet.
It's a bit unfortunate that 0 is actually the expected result there
for 1024x768. I think I'll move the test checking the entire DWORD
first and set the broken_occlusion flag based on that. I should
definitely use win_skip though.