Wine Test Shell - timeouts during test runs too short?

[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.

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

[Stefan Dösinger]

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.

[Reece Dunn]

On 27/01/2008, Stefan Dösinger <stefan(a)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

[Stefan Dösinger]

Am Sonntag, 27. Januar 2008 13:49:36 schrieb Reece Dunn:
> On 27/01/2008, Stefan Dösinger <stefan(a)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.