[PATCH v2 1/3] ddraw/tests: Test non-primary surface in test_lost_device.
hverbeet at gmail.com
Tue Jul 28 08:26:46 CDT 2020
On Tue, 28 Jul 2020 at 16:35, Gabriel Ivăncescu <gabrielopcode at gmail.com> wrote:
> On 28/07/2020 13:37, Henri Verbeet wrote:
> > On Mon, 27 Jul 2020 at 22:06, Gabriel Ivăncescu <gabrielopcode at gmail.com> wrote:
> >> On 27/07/2020 19:30, Stefan Dösinger wrote:
> >>> This will either create a video or system memory surface depending on
> >>> the whims of the driver. Since we already explicitly test offscreen
> >>> sysmem surfaces, shouldn't this one request video memory explicitly and
> >>> skip some tests if creation fails? That might make your broken(hr ==
> >>> DD_OK) /* WinXP */ go away.
> >> You're right, sorry, I'm not very familiar with ddraw. I tried with
> >> DDSCAPS_VIDEOMEMORY (and even DDSCAPS_LOCALVIDMEM, though it shouldn't
> >> be necessary), unfortunately it's still broken on Windows XP so that
> >> broken check has to stay.
> > Why do you consider the Windows XP result broken? DD_OK is what I
> > would expect for DDSCL_NORMAL.
> Well, I thought it's broken because it only applies to ddraw1 and on Win
> XP (not on Windows 7). The other ddraw have the same behavior as other
> Windows OSes and fail, too. So it seemed like the odd one out.
I see. The other ddraw versions are probably missing a Restore() call
though. I.e., my understanding of the expected behaviour is the
- In DDSCL_EXCLUSIVE mode, changing the foreground window makes
the device lost.
- In DDSCL_NORMAL mode, this does not happen.
A more subtle implication of that is that switching from exclusive
fullscreen to the normal cooperative level loses surfaces, due to the
order of the fullscreen/windowed change relative to the
exclusive/normal change. This is currently a todo_wine. On the other
hand, inserting a change to the normal fullscreen cooperative level in
between avoids losing surfaces.
After the change from exclusive fullscreen to normal, we recreate the
primary to make it non-flippable. This avoids a call to
RestoreAllSurfaces()/restore_surfaces(), but only because before this
patch the primary is the only surface that can get lost. Restoring
surfaces after recreating the primary should get rid of many of the
todo_wine/DDERR_SURFACELOST introduced in this patch.
The part that is unusual for ddraw1 compared to the other versions is
that surfaces do not appear to get lost during the change from
exclusive fullscreen to normal. This may be due to slight ordering
differences compared to the other versions (see also above). Seemingly
that's not entirely consistent between Windows versions or drivers
though, as the existing broken() seems to hint at. But once we're in
the normal cooperative level, we wouldn't expect window changes to
lose surfaces. In any case, I'd expect restoring surfaces after
recreating the primary to make the ddraw1 behaviour consistent again
with the other ddraw versions, and across Windows versions.
Last, and for what it's worth, the behaviour of older Windows versions
like Windows XP and Windows 98 is generally much more in line with
what ddraw applications expect. It's not unusual for older ddraw
applications in particular to simply not work on e.g. Windows 10
unless specific compatibility settings (or in some cases patches) are
More information about the wine-devel