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)