d3d: Add a slight delay before testing the ddraw and d3d9 visual tests

[Peter Dons Tychsen]

OK. I still think he should put a FIXME remark in the test-case,
and document why Sleep() is needed. Someone might fix the driver
someday. 

The only reason i yelled "alert!", is that i have seen so much bad code
which has come to a state where the are Sleep(143) here and Sleep(1332)
there, where nobody can remember why they are there and what the Sleep
count represents (most of the time no-one ever knew! :-)). In the mean
time, the real bugs just getter harder to 
find, as they are covered by all the messy Sleeps(). I see allot of this
kind of yap in telecom embedded software (mobile phones etc.).

In this case Maarten probably knows what he is doing (he usually does).
But thanks for the follow up!

And now i will go to Sleep().

Thanks,

/p

On Wed, 2008-02-13 at 11:28 +0100, Stefan Dösinger wrote:
> Am Mittwoch, 13. Februar 2008 03:11:24 schrieb Peter Dons Tychsen:
> > Eh, this does not seem like a proper way to get a unit test to pass.
> >
> > Sleep()... that leads to the dark side! :-)
> I talked to Maarten on IRC about this. The problem seems to be that his 
> monitor takes ages to mode switch, but ChangeDisplaySettings returns before 
> this modeswitch is done. Also the opengl driver attempts to draw before the 
> setup is ready, which fails and causes the test failures.
> 
> So it sounds like a driver bug which will only affect the tests(since games 
> draw repeatedly and do not care if the first few frames do not render 
> properly)