[PATCH v2 1/3] ddraw/tests: Test non-primary surface in test_lost_device.

Gabriel Ivăncescu gabrielopcode at gmail.com
Tue Jul 28 09:50:34 CDT 2020


On 28/07/2020 16:26, Henri Verbeet wrote:
> 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
> following:
> 
>      - 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
> used.
> 

That makes sense, thanks for the explanation. Restoring it did indeed 
solve it, I'll send updated patches shortly.



More information about the wine-devel mailing list