Re: [PATCH 1/4] ddraw/tests: Don't use DDBLT_COLORFILL in test_flip (v2).

[Marvin]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=30335

Your paranoid android.


=== w8 (32 bit ddraw1) ===
ddraw1.c:6945: Test failed: Got unexpected color 0x00000000.
ddraw1.c:6949: Test failed: Got unexpected color 0x00000000.
ddraw1.c:7012: Test failed: Got unexpected color 0x00000000.
ddraw1.c:7014: Test failed: Got unexpected color 0x00000000.

[PATCH 1/4] ddraw/tests: Don't use DDBLT_COLORFILL in test_flip (v2).

[Stefan Dösinger]

> === w8 (32 bit ddraw1) ===
> ddraw1.c:6945: Test failed: Got unexpected color 0x00000000.
> ddraw1.c:6949: Test failed: Got unexpected color 0x00000000.
> ddraw1.c:7012: Test failed: Got unexpected color 0x00000000.
> ddraw1.c:7014: Test failed: Got unexpected color 0x00000000.
> This is not from the test I modified and is a random failure. It didn't
> fail in 32 bit w864 or w1064 or in the same configuration in patch

Am 2017-04-21 um 17:32 schrieb Marvin:
133003.

This random failure and the one in test_texture_load are on my radar,
but so far I've had no luck figuring out why they happen. There is a
random rendering failure in ddraw1 on WARP. It appears that it is made
successively worse by previous tests. If I run only test_texture_load
and test_texturemapblend it runs successfully in an endless loop for
hours. Disabling other tests makes the bug successively less likely. The
problem is not texturing or loading the texture, the problem is that the
draw doesn't happen at all.

I am tempted to just move the two tests to the start of the file and
hope it makes the likelihood of the failure close to zero.