RFC - d3d9: Return success for UnlockRect attempts on already unlocked surfaces

[Bruno Jesus]

Hi all, this is an attempt to fix bug 28874 [1]. The tests [2] run
fine up to Windows 8, which unfortunately introduced a change in the
behavior so I'm not sure how to handle this (broken?).

Maybe a similar test is required in other d3d versions and a deeper
change (wined3d_surface_unmap?) required to proper fix this.

[1] - https://bugs.winehq.org/show_bug.cgi?id=28874
[2] - https://testbot.winehq.org/JobDetails.pl?Key=17252

Best wishes,
Bruno

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 2015-10-11 um 18:36 schrieb Bruno Jesus:
> - switch(hr)
> - if (hr == WINEDDERR_NOTLOCKED)
> {
> -
>    case WINEDDERR_NOTLOCKED:       return D3DERR_INVALIDCALL;
> -
>    default:                        return hr;
> -
>    TRACE("surface was not locked!\n");
> -
>    hr = S_OK;
> }

Buffers already behave like this, but I believe we have a test that
shows surfaces and textures behave differently.

Either way what we need is a test for all d3d versions, from
dlls/ddraw/tests/ddraw1.c to d3d11. If all of them behave in the same
way we can return WINED3D_OK in wined3d, otherwise we'll have to catch
this in the client library.

I vaguely remember that there was some difference between
IDirect3DTexture9_LockRect and IDirect3DSurface9_LockRect on a surface
that was retrieved from that texture. It's also possible that there's a
difference between stand-alone surfaces and textures, and / or different
pools.
> Hi all, this is an attempt to fix bug 28874 [1]. The tests [2] run
> fine up to Windows 8, which unfortunately introduced a change in the
> behavior so I'm not sure how to handle this (broken?).

So Windows <= 7 have the behavior the game expects, whereas Windows 8
and 10 have a different behavior? Yeah, in this case accept the 8+
behavior as broken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWG3N6AAoJEN0/YqbEcdMw2EQP/jqIJpo+4kkOU810zx8UqgkQ
cQXB9hQQdQrq2rMda9j02YNd47KivtY+ydLmkd0s5iOV0v0j4Q563JLCYVNlRuVp
db4ylVMFkYGxW6sYqW5zDPSPyIcnj/bXNCBlYqx5eeO5JisaScDMzcdMhj/g1z1f
MSHtmbyIvYcX4/GF1jOc6VKmPcVHS2TSG3VeE6S+giTPawtgRYypcJ5AWbbYhU1T
3kN6yQ73kIRLal8BJFYYwjhXRyTVGPm4dLhYCwlJf73BKtX6/q7uVoSUcfy3HQiP
q6keerqTIHAbPOOxwWbaxSMAz+t/8i3yquTUctB4FjE6e3t8hHRWSgq+DDOOVMyF
HC4RRBfVAJgH3ThSIOONpe9YorAMRGNkj8t6zbq13t4Tul9aRi7P5LfEmpALTLzM
cuRDxmki/p9ZED4HGeSHHpKBviXKe8zQFPPOagS25dn2CH1qWd+WBO90aJL6tOTk
FZz4mAXsL/qSuNBMqkvdFDXc62UNyYm5nqlsaG5cRUHeweIAc55AgROApKPbFj7o
VUa216IiCG+l4wdC3ObeG2Qd+w74a99NUmobV8P9pNyUBlOcUYTFz89vdu+tBe2R
4Ao11g4mZkQ5elwVAi1lt12F5Zd4zxOIdvhuhmQVNULk2SzyPdr19I6bz06djDyU
PbXg1YTGUjTK4AmG6hFG
=kzKn
-----END PGP SIGNATURE-----

[Henri Verbeet]

On 12 October 2015 at 10:46, Stefan Dösinger  wrote:
> Either way what we need is a test for all d3d versions, from
> dlls/ddraw/tests/ddraw1.c to d3d11. If all of them behave in the same
> way we can return WINED3D_OK in wined3d, otherwise we'll have to catch
> this in the client library.

Yeah. Note that d3d9ex test_user_memory() may not be the best place to
test the general d3d9 behaviour.