Hi,
When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places.
These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow.
The others (such as kernel32:debugger) may be the same - especially when you get mixed results from different runs.
Because of this, the timeout length should be increased (I would say at least doubled, to allow the long-running tests to run through).
Another thing... I find it breaks the idea of an automated test run to have to watch it to OK the timeout messages. I know that UAC and the shfileop tests bring up interactive dialogs, but these are from within Windows itself, and will be dealt with by the timeout/test killer part of the Wine Test Shell.
This would help make it easier for people to run the tests more often.
- Reece
Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn:
Hi,
When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places.
These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow.
If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds.
I've considered using the Reference rasterizer, which is even slower, as a fallback for the d3d9 tests, however, running the d3d9 visual tests in the refrast in qemu takes approximately 5 hours, so I dropped the idea. Furthermore the d3d9 refrast has to be installed separately.
On 27/01/2008, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn:
Hi,
When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places.
These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow.
If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds.
These are running on a decent spec Vista machine that is not running through VM.
I don't know if 3D acceleration is on; it looks like it is off (the colour gradiant sweep tests take a while to flick through). This is strange though, because it is the default configuration for the Vista machine and games like Oblivion and Command and Conquer 3 play fine (but those are using D3D, not DDraw).
Do you know how to turn 3D acceleration on in Vista?
That said, Wine Test Shell should accept this as a valid test run and not timeout.
- Reece
Am Sonntag, 27. Januar 2008 13:49:36 schrieb Reece Dunn:
On 27/01/2008, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 27. Januar 2008 12:18:12 schrieb Reece Dunn:
Hi,
When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places.
These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow.
If you don't have a 3D accelerator(e.g. running in a VM), the ddraw d3d and visual tests will attempt to use the RGB software rendering device, which *is* slow. Running the visual test takes a few minutes instead of a few secounds.
These are running on a decent spec Vista machine that is not running through VM.
I don't know if 3D acceleration is on; it looks like it is off (the colour gradiant sweep tests take a while to flick through). This is strange though, because it is the default configuration for the Vista machine and games like Oblivion and Command and Conquer 3 play fine (but those are using D3D, not DDraw).
The ddraw "d3d" and "visual" tests use d3d - earliear d3d versions(d3d <= 7) are a subset of ddraw.dll . It could be that your driver doesn't like something about the way the test initializes d3d, so the test falls back to the software renderer.
-
Reece Dunn -
Stefan Dösinger