assuming that this test is indeed useful in the first place, which it indeed may not be.
I've taken some advice from @huw on this one. We decided the tests may be worth keeping to validate the Wine implementation, but I've added a new column to record the `studio_value` and I use this value to mark a test broken; even though technically it's not broken, it's just the graphics card has been set-up differently.
I don't think that it should be marked broken, no, not when the actual behaviour of d3d is not documented anywhere. (The cited Microsoft documentation is for Media Foundation, which is orthogonal to Direct3D). I especially don't think it makes sense to mark behaviour broken which is universal across drivers, i.e. the lack of a difference between "SD" and "HD" values based on image size.
If WARP has unique results, that's something we generally consider broken. If results contradict documented behaviour or are clearly the result of a bug, that's also broken. Otherwise, since there isn't really a Direct3D spec, we treat any reasonable behaviour as valid.
I'm not opposed to modifying Wine anyway, although the only particularly salient reason I would see to do so is "it makes an application look better". The behaviours of other media decoding libraries aren't particularly relevant here.
I am curious if the application in question displays the same colour range on an NVidia Windows machine in its default configuration. I was going to test this myself, but hadn't had a chance to do so yet.
I had to raise the tolerance a bit (4 seems to work)
I've increased the tolerance for Windows to allow 4. In that the test will pass on Wine and Windows if the tolerance is within 1, but it will be marked broken on Windows if between 1 and 4 (and fail on Wine). The tests are a bit different to usual for this one, I guess because we're not testing against core Windows behavior, but against the settings and implementation of the graphics card driver. But the tests now ~~pass~~ don't fail on the different test bot systems.
I'd just leave it as 4 universally; there's no reason to hold Wine to a stricter standard than Windows.
Some tests actually pass with the current implementation, so I do need a `todo_wine_if`.
Oops, I misread, sorry.
I decided the tests were a bit difficult to read, so I've reformatted and used the member names of the struct during initialization.
Ehh... I don't want to bikeshed, but the way in which I misread is not really helped by the reformatting, and while I'm fine with accepting the new version, I think the inline table was better.