On 21 October 2013 10:47, Lasse Rasinen lrasinen@iki.fi wrote:
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index 7932a7f..52cf27a 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -4022,8 +4022,12 @@ static void test_lockrect_invalid(void)
hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr);
- locked_rect.pBits = 0xdeadbeef;
- locked_rect.Pitch = 1; hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr);
- ok(locked_rect.pBits == 0xdeadbeef, "pBits changed on double lock.\n");
- ok(locked_rect.Pitch == 1, "Pitch changed on double lock.\n"); hr = IDirect3DSurface8_UnlockRect(surface); ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr);
This test fails for me on Windows 7:
device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock.
As an aside, if you had written the messages as "Got unexpected pBits %p.\n" and "Got unexpected Pitch %d.\n", you would have gotten the following output instead:
device.c:4029: Test failed: Got unexpected pBits 00000000. device.c:4030: Test failed: Got unexpected Pitch 0.
On 21.10.2013, at 14.46, Henri Verbeet wrote:
On 21 October 2013 10:47, Lasse Rasinen lrasinen@iki.fi wrote:
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index 7932a7f..52cf27a 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -4022,8 +4022,12 @@ static void test_lockrect_invalid(void)
hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr);
- locked_rect.pBits = 0xdeadbeef;
- locked_rect.Pitch = 1; hr = IDirect3DSurface8_LockRect(surface, &locked_rect, NULL, 0); ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr);
- ok(locked_rect.pBits == 0xdeadbeef, "pBits changed on double lock.\n");
- ok(locked_rect.Pitch == 1, "Pitch changed on double lock.\n"); hr = IDirect3DSurface8_UnlockRect(surface); ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr);
This test fails for me on Windows 7:
device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock.
So on one W7 computer the struct gets cleared, on another it is kept.
Any advice on how to continue? For my use case, either solution will work.
As an aside, if you had written the messages as "Got unexpected pBits %p.\n" and "Got unexpected Pitch %d.\n", you would have gotten the following output instead:
device.c:4029: Test failed: Got unexpected pBits 00000000. device.c:4030: Test failed: Got unexpected Pitch 0.
Advice taken.
On 21 October 2013 13:52, Lasse Rasinen lrasinen@iki.fi wrote:
On 21.10.2013, at 14.46, Henri Verbeet wrote:
This test fails for me on Windows 7:
device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock.
So on one W7 computer the struct gets cleared, on another it is kept.
Is that on your own machine, or did I miss those results?
Any advice on how to continue? For my use case, either solution will work.
If the results here really are inconsistent between machines, and no application cares, you can probably just drop this patch. On the other hand, if applications expect e.g. either NULL, or the original value, you could instead write the test as "ok(!locked_rect.pBits || locked_rect.pBits == (void *)0xdeadbeef, ...);" and add an appropriate comment.
On 21.10.2013, at 15.08, Henri Verbeet wrote:
On 21 October 2013 13:52, Lasse Rasinen lrasinen@iki.fi wrote:
On 21.10.2013, at 14.46, Henri Verbeet wrote:
This test fails for me on Windows 7:
device.c:4029: Test failed: pBits changed on double lock. device.c:4030: Test failed: Pitch changed on double lock.
So on one W7 computer the struct gets cleared, on another it is kept.
Is that on your own machine, or did I miss those results?
Buildbot on the previous patch and Stefan Dösinger on Friday.
Any advice on how to continue? For my use case, either solution will work.
If the results here really are inconsistent between machines, and no application cares, you can probably just drop this patch. On the other hand, if applications expect e.g. either NULL, or the original value, you could instead write the test as "ok(!locked_rect.pBits || locked_rect.pBits == (void *)0xdeadbeef, ...);" and add an appropriate comment.
There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test.
On 21 October 2013 14:12, Lasse Rasinen lrasinen@iki.fi wrote:
Buildbot on the previous patch and Stefan Dösinger on Friday.
https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it passed the test that checked for NULL pBits and 0 Pitch. AFAIK Stefan didn't test d3d8 at all.
There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test.
Isn't that d3d9?
On 21.10.2013, at 15.23, Henri Verbeet wrote:
On 21 October 2013 14:12, Lasse Rasinen lrasinen@iki.fi wrote:
Buildbot on the previous patch and Stefan Dösinger on Friday.
https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it passed the test that checked for NULL pBits and 0 Pitch. AFAIK Stefan didn't test d3d8 at all.
There's the one misbehaving app (Artemis spaceship sim) that cares. Will update test.
Isn't that d3d9?
D'oh. I can't read, apparently. Apologies.
In that case, yes, this patch can be dropped; let's see what the buildbot thinks about the other one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-10-21 14:31, schrieb Lasse Rasinen:
On 21.10.2013, at 15.23, Henri Verbeet wrote:
On 21 October 2013 14:12, Lasse Rasinen lrasinen@iki.fi wrote:
Buildbot on the previous patch and Stefan Dösinger on Friday.
https://newtestbot.winehq.org/JobDetails.pl?Key=2784 says it passed the test that checked for NULL pBits and 0 Pitch. AFAIK Stefan didn't test d3d8 at all.
Fyi, I tested the d3d8 behavior, and it consistently sets pBits and pitch to 0 on all tested machines:
WinXP, ATI r200 (radeon 9000) WinVista, Nvidia G7x (geforce 7400) Win7, ATI r500 (radeon x1600) Win7, Nvidia Fermi (Geforce 460) Win7, AMD Evergreen (radeon hd 5770)
D3D9 left those fields untouched. For d3d9 I only tested WinXP+r200 and Win7+Kepler. Volumes clear pBits and both pitches in d3d9 on those cards and presumably all others.
-
Henri Verbeet -
Lasse Rasinen -
Stefan Dösinger