[PATCH 3/3] d3d9/tests: Improve testing of display formats and IDirect3D9_CheckDeviceType().

[Ken Thomases]

On Jan 27, 2014, at 5:16 AM, Henri Verbeet wrote:

> On 22 January 2014 23:42, Ken Thomases <ken at codeweavers.com> wrote:
>> 
>> Consolidates duplicated code by using a simpler table-driven mechanism.
>> Instead of manually listing out certain combinations of display formats vs.
>> backbuffer formats, it just lists the formats and some metadata about them.
>> The algorithm tests every format against every format, using the metadata
>> to predict success or failure.  This also tests that CheckDeviceType() fails
>> for display formats for which there are no adapter modes, rather than
>> skipping those.
>> 
>> Tests windowed mode.
>> ---
>> dlls/d3d9/tests/device.c |  162 ++++++++++++++++++----------------------------
>> 1 files changed, 64 insertions(+), 98 deletions(-)
>> 
> 
> This fails on native (Win 7, AMD Radeon HD 6310)

That's very peculiar.  This:

> device.c:2316: Display format D3DFMT_X1R5G5B5 not supported

means that IDirect3D9_GetAdapterModeCount(…, D3DFMT_X1R5G5B5) returned 0 modes.  This:

> device.c:2347: Testing display format D3DFMT_X1R5G5B5, backbuffer format D3DFMT_R5G6B5, windowed 1, shouldPass 0
> device.c:2357: Test failed: format D3DFMT_X1R5G5B5(24) D3DFMT_R5G6B5(23) windowed passed while it wasn't expected to

means that IDirect3D9_CheckDeviceType(…, D3DFMT_X1R5G5B5, D3DFMT_R5G6B5, TRUE) succeeded.

I would not have expected that CheckDeviceType() would succeed if the DisplayFormat parameter was one which the adapter doesn't support modes for.  Prior to my patch, the CheckDeviceType() test would have been skipped when the adapter doesn't provide modes for the display format.  I can go back to that, but it seems unfortunate.  This result is telling us something potentially important about the behavior of CheckDeviceType().

Do you think I should just ignore "nmodes" for windowed mode?  It seems like the test is saying that CheckDeviceType() doesn't care whether the display format is supported for windowed mode.  Of course, it's unreliable to extrapolate from a single data point.

> … and produces quite a lot of output in general

Yeah, although there was a corresponding trace() in the X8R8G8B8 loop in the old code.  Since I was consolidating multiple loops into one, I took the union of the features of all of the loops.  I can reduce that if you like.

Thanks for testing on native.  And to anybody else listening, I would appreciate more tests on native.

-Ken