February 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.

by Henri Verbeet

On 20 February 2015 at 13:59, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > The code Henri uses in convert_s1_uint_d15_unorm looks reasonable, but > I did not find a textbook explanation for it. Repeating the high bits > in the extra space seems reasonable, but I'm not sure what the reason > for ORing the least significant bit is. > It's supposed to be the stencil data. Note that that code probably hasn't seen a lot of testing though, since in practice it's probably only used for the upload of the initial surface contents. I.e., zeroes.

Feb. 20, 2015

Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-20 um 13:50 schrieb Matteo Bruni: > Yes, I've noticed that too. I haven't really looked into it but > the float-to-signed conversion has always been a bit tricky. In > OpenGL AFAIK the conversion formula changed at some point (e.g. see > table 2.9 in the 2.1 spec vs paragraph 2.3.5.1 in the 4.5 spec), it > might be we have to use one instead of the other in our fallback > conversion functions too. No idea if something like that applies to > Windows drivers too. Well, one problem we have in e.g. L6V5U5 is that we simply left-shift by 3. So the input value 15 / 0xf, which is the highest possible value for the signed channels becomes 120 (0x78). This doesn't give the same float result. The code Henri uses in convert_s1_uint_d15_unorm looks reasonable, but I did not find a textbook explanation for it. Repeating the high bits in the extra space seems reasonable, but I'm not sure what the reason for ORing the least significant bit is. Also I'm not sure what the correct handling of negative ranges is. I *think* it's enough to just left-shift them, but I am not sure. Also, as the OpenGL spec says, representing zero is an issue. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5y+xAAoJEN0/YqbEcdMwzYEP/30SOtzipbgTFGyU9i5uvAl2 wnDxoteqdBQjk8UwIqM933uHDsuDBXZBLzEvtG7lWq83Sf/n7qWkQf69n/Ek5vuh EWgdxN2jVXa3jboBHdSWAagcS0uBlj4Z5BHewiXXdNHHbPOO34aKHOztK+j8B1Sp PhcHR4LT1XZy6KkXS4nh6L3V9vyB8U0FADmDuumy47RcZ0b+cGsghpk/AZ5ULb4K uck1XwjOVWV+i9j9YErxzoCBzDooKG2oUYuQti2N2G5ae4pqGc9H8dTvQJ2l/Pt4 MxT0R/wa05mPSLCNl+u9qHWRlZ677g8JlvWD5diqgeD2k09dvlS2aahMSveFreu9 33uBil2eRP8hKioafCVNJ/efDnFCKcayi/UmUTfISpwZ3gwI3V/aNKaoN6CGtlAm DtTGn25lDWZrPOt/h2zon+NoYBLFMkW+ZOnEIrVVB6OBtRrAnJDKVkj2CE7XMJkz Vzw9xozGRJ+nHi2RdsEOqT4dcAzKvZgdtVL2+jgKehNzAagOKPTjfhmf+kcyOu05 V3cNwowaZmagvrknxDWaMzI0TM530UTimqEkXhY7oIwpHV3qT40GOFyjQM/hu1nB ZvMLB7978IK0fMLAhZi8KuM7eFTsHWgOtTyf2AvxzIZnSADJkGs2FlKXvOkTCnaP Dmbwu+WVecEXL/3xRAdK =Kr2P -----END PGP SIGNATURE-----

Feb. 20, 2015

Re: [PATCH 5/5] d3d9/tests: Move a Present out of the loops in fog_with_shader_test().

by Matteo Bruni

2015-02-20 13:33 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 20 February 2015 at 13:06, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> It reduces the duration of the visual test with all the other functions >> from visual.c compiled out from 9 to 1.5 seconds for me (on a Radeon >> HD 5650M, Linux, Mesa). >> --- > For what it's worth, I think we can actually just remove most of the > Present() calls in the tests. It's perhaps fun to keep for nostalgic > reasons, but I think the only time anyone really wants to see what > gets drawn is while debugging failures. Yeah, I don't know. I just "fixed" the worst offender in my case. We might want to keep just one present per test for the fun factor or remove them all, either is fine to me. This was mostly to show that those Present do take a lot of time, at least on some HW configurations.

Feb. 20, 2015

Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.

by Matteo Bruni

2015-02-20 13:29 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I am working on a more comprehensive test for V8U8, V16U16, L6V5U5, > X8L8V8U8 and Q8W8V8U8. I have attached the current status of this > test. I am still struggling with finding the right precision that > makes all Windows machines happy. There are also some problems with > our conversion code. Yes, I've noticed that too. I haven't really looked into it but the float-to-signed conversion has always been a bit tricky. In OpenGL AFAIK the conversion formula changed at some point (e.g. see table 2.9 in the 2.1 spec vs paragraph 2.3.5.1 in the 4.5 spec), it might be we have to use one instead of the other in our fallback conversion functions too. No idea if something like that applies to Windows drivers too. > Your test tests the case of a non-even width, whereas my test doesn't > do that. I can build that into my test as well. > > We can still commit your test if you want, and I'll remove it again in > my patch (together with x8l8v8u8_test). I just wrote (more like copypasted and edited) this test to make sure I didn't screw up patch 1/5 and since I wrote it I though "why not send it too". It's fine for me either way.

Feb. 20, 2015

Re: [PATCH 5/5] d3d9/tests: Move a Present out of the loops in fog_with_shader_test().

by Henri Verbeet

On 20 February 2015 at 13:06, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It reduces the duration of the visual test with all the other functions > from visual.c compiled out from 9 to 1.5 seconds for me (on a Radeon > HD 5650M, Linux, Mesa). > --- For what it's worth, I think we can actually just remove most of the Present() calls in the tests. It's perhaps fun to keep for nostalgic reasons, but I think the only time anyone really wants to see what gets drawn is while debugging failures.

Feb. 20, 2015

Re: [PATCH 2/5] d3d9/tests: Add a test for 2D D3DFMT_V16U16 textures.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am working on a more comprehensive test for V8U8, V16U16, L6V5U5, X8L8V8U8 and Q8W8V8U8. I have attached the current status of this test. I am still struggling with finding the right precision that makes all Windows machines happy. There are also some problems with our conversion code. Your test tests the case of a non-even width, whereas my test doesn't do that. I can build that into my test as well. We can still commit your test if you want, and I'll remove it again in my patch (together with x8l8v8u8_test). Stefan Am 2015-02-20 um 13:06 schrieb Matteo Bruni: > --- > dlls/d3d9/tests/visual.c | 148 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 148 insertions(+) > > diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c > index 5f64ec3..2152ba6 100644 > --- a/dlls/d3d9/tests/visual.c > +++ b/dlls/d3d9/tests/visual.c > @@ -16208,6 +16208,153 @@ done: > DestroyWindow(window); > } > > +static void v16u16_test(void) > +{ > + IDirect3DTexture9 *texture; > + IDirect3DPixelShader9 *shader; > + IDirect3DDevice9 *device; > + D3DLOCKED_RECT rect; > + IDirect3D9 *d3d; > + unsigned int i; > + ULONG refcount; > + D3DCAPS9 caps; > + SHORT *texel; > + DWORD color; > + HWND window; > + HRESULT hr; > + > + static const struct > + { > + struct vec3 position; > + struct vec2 texcrd; > + } > + quads[] = > + { > + {{-1.0f, -1.0f, 0.0f}, {0.0f, 0.0f}}, > + {{-1.0f, 1.0f, 0.0f}, {0.0f, 1.0f}}, > + {{ 1.0f, -1.0f, 1.0f}, {1.0f, 0.0f}}, > + {{ 1.0f, 1.0f, 1.0f}, {1.0f, 1.0f}}, > + }; > + static const DWORD shader_code[] = > + { > + 0xffff0101, /* ps_1_1 */ > + 0x00000051, 0xa00f0000, 0x3f000000, 0x3f000000, /* def c0, 0.5, 0.5, */ > + 0x3f000000, 0x3f000000, /* 0.5, 0.5 */ > + 0x00000042, 0xb00f0000, /* tex t0 */ > + 0x00000004, 0x800f0000, 0xb0e40000, 0xa0e40000, 0xa0e40000, /* mad r0, t0, c0, c0 */ > + 0x0000ffff /* end */ > + }; > + > + window = CreateWindowA("static", "d3d9_test", WS_OVERLAPPEDWINDOW | WS_VISIBLE, > + 0, 0, 640, 480, NULL, NULL, NULL, NULL); > + d3d = Direct3DCreate9(D3D_SDK_VERSION); > + ok(!!d3d, "Failed to create a D3D object.\n"); > + if (!(device = create_device(d3d, window, window, TRUE))) > + { > + skip("Failed to create a D3D device, skipping tests.\n"); > + goto done; > + } > + > + hr = IDirect3DDevice9_GetDeviceCaps(device, &caps); > + ok(SUCCEEDED(hr), "Failed to get device caps, hr %#x.\n", hr); > + if (caps.PixelShaderVersion < D3DPS_VERSION(1, 1)) > + { > + skip("No ps_1_1 support, skipping tests.\n"); > + IDirect3DDevice9_Release(device); > + goto done; > + } > + if (FAILED(IDirect3D9_CheckDeviceFormat(d3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, > + D3DFMT_X8R8G8B8, 0, D3DRTYPE_TEXTURE, D3DFMT_V16U16))) > + { > + skip("V16U16 textures are not supported, skipping test.\n"); > + IDirect3DDevice9_Release(device); > + goto done; > + } > + > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | D3DFVF_TEX1); > + ok(SUCCEEDED(hr), "Failed to set FVF, hr %#x.\n", hr); > + hr = IDirect3DDevice9_CreatePixelShader(device, shader_code, &shader); > + ok(SUCCEEDED(hr), "Failed to create pixel shader, hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetPixelShader(device, shader); > + ok(SUCCEEDED(hr), "Failed to set pixel shader, hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetSamplerState(device, 0, D3DSAMP_MAGFILTER, D3DTEXF_POINT); > + ok(SUCCEEDED(hr), "Failed to set filter, hr %#x.\n", hr); > + > + for (i = 0; i < 2; ++i) > + { > + D3DPOOL pool; > + > + if (i) > + pool = D3DPOOL_SYSTEMMEM; > + else > + pool = D3DPOOL_MANAGED; > + > + hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16, > + pool, &texture, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + > + hr = IDirect3DTexture9_LockRect(texture, 0, &rect, NULL, 0); > + ok(SUCCEEDED(hr), "Failed to lock texture, hr %#x.\n", hr); > + > + texel = (SHORT *)((BYTE *)rect.pBits + 0 * rect.Pitch); > + texel[0] = 32767; > + texel[1] = 32767; > + texel = (SHORT *)((BYTE *)rect.pBits + 1 * rect.Pitch); > + texel[0] = -32768; > + texel[1] = 0; > + > + hr = IDirect3DTexture9_UnlockRect(texture, 0); > + ok(SUCCEEDED(hr), "Failed to unlock texture, hr %#x.\n", hr); > + > + if (i) > + { > + IDirect3DTexture9 *texture2; > + > + hr = IDirect3DDevice9_CreateTexture(device, 1, 2, 1, 0, D3DFMT_V16U16, > + D3DPOOL_DEFAULT, &texture2, NULL); > + ok(SUCCEEDED(hr), "Failed to create texture, hr %#x.\n", hr); > + > + hr = IDirect3DDevice9_UpdateTexture(device, (IDirect3DBaseTexture9 *)texture, > + (IDirect3DBaseTexture9 *)texture2); > + ok(SUCCEEDED(hr), "Failed to update texture, hr %#x.\n", hr); > + > + IDirect3DTexture9_Release(texture); > + texture = texture2; > + } > + > + hr = IDirect3DDevice9_SetTexture(device, 0, (IDirect3DBaseTexture9 *)texture); > + ok(SUCCEEDED(hr), "Failed to set texture, hr %#x.\n", hr); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00ff00ff, 1.0f, 0); > + ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr); > + hr = IDirect3DDevice9_BeginScene(device); > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, &quads[0], sizeof(*quads)); > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > + > + color = getPixelColor(device, 320, 160); > + ok (color_match(color, 0x00007fff, 1), > + "Expected color 0x00007fff, got %#x, V16U16 input -32768, 0.\n", color); > + color = getPixelColor(device, 320, 400); > + ok (color_match(color, 0x00ffffff, 1), > + "Expected color 0x00ffffff, got %#x, V16U16 input 32767, 32767.\n", color); > + > + hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); > + ok(SUCCEEDED(hr), "Failed to present, hr %#x.\n", hr); > + > + IDirect3DVolumeTexture9_Release(texture); > + } > + > + IDirect3DPixelShader9_Release(shader); > + refcount = IDirect3DDevice9_Release(device); > + ok(!refcount, "Device has %u references left.\n", refcount); > +done: > + IDirect3D9_Release(d3d); > + DestroyWindow(window); > +} > + > static void add_dirty_rect_test_draw(IDirect3DDevice9 *device) > { > HRESULT hr; > @@ -17566,6 +17713,7 @@ START_TEST(visual) > texkill_test(); > x8l8v8u8_test(); > volume_v16u16_test(); > + v16u16_test(); > constant_clamp_ps_test(); > cnd_test(); > dp2add_ps_test(); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5yi0AAoJEN0/YqbEcdMwXdcP/2QHNZaeHncB/4If+JfpQEOv Vto9Z3ip/eGDuOCRylNjiL47VZfYyuqXHe8EoGzKkuGmtGvPjr2ZhkebUf0l9OIN g2LAqQIa17nYTJFnO6ofzHjcWb++mdIDG1lVUJFKyhIS2vl0xjfB3V4wteMLDffS R6CTtAS49vxFL2lzDwrWaEj2SYhnnybNoKLdhOY5jXH31kcz5W9k3Fzr5Umb2dPB q3tyZHZtYHHsR5kXCmJO6DA456y8euFqzR9GK5/0nDUlh8CGV74pPL6pZMnoPn7c ssXU4HzPB9zPI6zVZBTV8+oOmHWFDn1YZL1M/w50rxY35XvjkU3vs4oezuHMkZBS wXt30QYWBRhFFB3Z2lq9jv9JZXA9V2+A8WmJMbblgv662QsctIAmT9ZAc2xycm7R ye89fHEC3xXFmM6jdJqS1k5MrA5R1li5YFbS18ujcAXVYCW3v8JtK0G05h2zy9e1 KifoVA8o+cVV0Sh2GtYoifLSNvpYo2AlCrP7/cjOyR6igiShK5pF+pktRIlsraM2 3Hl0wGjr2TPhTCTQQPKsskVNvKE+017e4+fwaFI8fRgF3zYSgLSKZELPFY05bzBX OOcbNSEqjRkFtoQoerBR7vx7yrU+85lwd945AGS3URF8KqkavK1LYsAfmLnFu90y YltdeSdbSvQDHCQ4CmmL =D2Pe -----END PGP SIGNATURE-----

Feb. 20, 2015

Re: [PATCH 2/3] ntdll/tests: Add tests for RtlIpv6StringToAddress (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-20 um 11:47 schrieb Stefan Dösinger: > Hi, > > Thanks again for your work and patience! This goes in the right > direction in my eyes. The full set of address tests are run against > both versions, and it documents the differences between non-ex and > ex better. Can you do the same with the ipv4 tests in patch 1? If you want you can move the ipv4 test to the end of the patch series and focus on the ipv6 tests first - that way we can see if we find any more corner cases before you do all the refactoring work on the ipv4 test data. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5xPjAAoJEN0/YqbEcdMwFL4P/0881Lo0n/fCEFV7oZm1oG78 wAiQPuHxVKQT6jyTifqfIt14PNUoBc5Y9GpRwIUjkhZ+8DJgyTg9ceCa3Wzxqs+n gy4Nac59LmDKALM7CHnYixF4rNc509ompZSMBH9WVWvlTtyYW6m+qXDbs+uSKYpz fsbZRI5vSP9/8fgyuVZOx7Ngt91C6S7mKn6Ub0dzfjwwDnV3Tv6h1lqLaJ3N4cuQ ogMbAuWSHzikU3LXe+3vIlqNPgfcwe8Eo9jM72ad/35ElO7y9rQZr6k+V2DPl4RN yk55zvXn2nzlJwQHZyIdhRIp/odeDFQXEyj1u5lJHEclDuqZYhtBppbTdBtFiVbd Kfu9To+d9feTzOMdKB58p2VYkjE8Mz86np35OMkp2+r6ytQK8EcCkkYZ51KhW0EQ kVVkmxLcmG/5YtuxQ4fnRMayc1m4cVoLy8FNRYjpvHffm/wtEuQtHDfF9jDTVwOz O8DRHX/96DJbE5Pbp3OXWPk6/Iq5l7wYIBXpDn1ENwwYG0vCb2/kj8JGoQ4OfLjf jUJ/B80W6NCjoHkaWJcNHnw/oPAPHc0H/UU/sucTCfGJw9gmx9s9wSaCLx9LFse3 vmTM7oUFgVUr6fLHxY/Uhs9VCDu94Vumbx6N7CU3VbZSmeBs5RYLie4gi/ZywkYS M2QugqvFbxmEWY8bNc2q =/GAT -----END PGP SIGNATURE-----

Feb. 20, 2015

Re: Is it possible to detect if a variable is in stack or heap based on its address?

by Bruno Jesus

On Fri, Feb 20, 2015 at 1:04 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 19, 2015, at 7:53 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> Can I be sure the first printed value is from stack and the second from heap? > > Are you asking whether that function will print an address on the stack and an address from the heap? Yes, it will. Or are you asking if you can determine the difference between the two types of pointers just by inspection? I don't think there are hard-and-fast rules, but with experience you can make a pretty good guess. For example, at least on OS X (32-bit), addresses around 0x0033nnnn are typical of the first thread's stack. You'll see a lot of those as arguments in a relay log because it's common to pass the address of a local in function calls. Thank you very much, all information was useful. > >> A plus question would be: Is it possible to know if an address is a >> const string? > > Do you mean a *static* const string? If it is, it will be from a mapped executable image. A +virtual log will show the address ranges to which images are loaded. I mean: void test(char *p) { if(magic_test_ptr(p)) //this is a string declared with "" else //this is not a string declared with "" } void test2() { char p[10]; test("1234"); test(p); } Best wishes, Bruno

Feb. 20, 2015

Re: [PATCH 2/3] ntdll/tests: Add tests for RtlIpv6StringToAddress (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks again for your work and patience! This goes in the right direction in my eyes. The full set of address tests are run against both versions, and it documents the differences between non-ex and ex better. Can you do the same with the ipv4 tests in patch 1? Am 2015-02-19 um 23:38 schrieb Mark Jansen: > +/* ipv6 addresses from https://github.com/beaugunderson/javascript-ipv6/tree/master/test/data */ > +static const struct > +{ > + PCSTR address; > + NTSTATUS res; > + int terminator_offset; > + int ip[8]; > + int broken; What is the meaning of broken here? Different behavior among different Windows versions? Or deviation from your source above? > + int ex_fails; /* 1 means ex should fail, 2 means skip for ex */ Style hint: You can use an enum in this case. I guess you need the skip value because the last test fails on non-ex and succeeds on ex and your expected address does not match. Similarly, the behavior that the function writes to the output address even in case of a failure isn't exactly helpful. - From patch 3: > + if (ipv6_tests[i].ex_fails == 2) /* testing vs ex doesnt >make sense. */ > + continue; Please document why, it took me a while to come up with the guess above. (And I'm not even sure it's the real reason). You're also not checking the output IP for the IP tests from the non-ex tests here. Is there a reason for that? Are there any cases where -Ex returns a different IP than non-ex? > + if (ipv6_tests[i].ip[0] == -1) > + { > + for (j = 0; j < 8; ++j) > + expected_ip.s6_words[j] = 0xabab; > + } I guess you want to avoid writing 0xabab 8 times in the table. I don't have any objection, but I can't predict if Alexandre likes it - technically this is redundant code. I'd say keep it for now, if he doesn't like it he will tell you. > + for (j = 0; j < 8; ++j) > + expected_ip.s6_words[j] = ipv6_tests[i].ip[j]; Would this do the right thing on big endian machines? About some individual tests: > + { "1111:2222:3333:4444:5555:6666:7777::", STATUS_SUCCESS, 34, { 0x1111, 0x2222, 0x3333, 0x4444, 0x5555, 0x6666, 0x7777, 0 }, 1 }, Now that's an interesting corner case. Out of curiosity, what does "1111:2222:3333:4444:5555:6666:7777:" do in non-ex and ex (one : removed)? > + { "::0:0:0:0:0:0:0", STATUS_SUCCESS, 13, { 0, 0, 0, 0, 0, 0, 0, 0 }, 0, 1 }, > + { "::0:a:b:c:d:e:f", STATUS_SUCCESS, 13, { 0, 0, 0, 0xa00, 0xb00, 0xc00, 0xd00, 0xe00 }, 0, 1 }, Here it would be interesting to know what IP -Ex writes before it fails. I don't see why -Ex would fail if -Ex calls non-ex, given that the terminator points way beyond the problematic "::" at the start. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5xDbAAoJEN0/YqbEcdMwmEIP/0ti3aPWMeI8yetig2eTIuAG 2QhNad7bgFgioJBremjKPDuDJViYhkv4XoIwie6bRFSF9VnEECmiv2wObhRz2e0E MgK1bGkZc0BXs4TiVoa/+JVxWgo3ddWn1Wpj+hyVRAvyEfj4NNfRWvcGaQ+cZmwu Sd0tx7BqCQLSPnNwyrl53nqVWjkkmARdSF2pLDMgXkwtGXlR2b2irYslYg+Sqgvb +ORAryKZvVLt8vL6wBclb8ruFWpro7/Rio6eZb8EfoRNH+8YdYWUrdfcoCE4Ui0i W2xsOnahZuPvuQR9id8zp4etIa+YrlGlVsIfHZrzDzCvbyuBlq+niSeWZxgNwMs+ IUpHoHj0TYNUZ9A7PB16UPHowsPVE5GYvsdjFr4Rj8rHxQqvftpTwFxRqWuV4qkQ Qx+achRcfA/qXWWYHksENuQJxF29vIbgiLbpvW256A6zmsAvB/+LlqndeF+BuW4I 3rQ2H7ADBAMx8IscePSDNLAKd2vsYWj8gFlw7y10HnIE7/zedqtWPIaGocFnS0u5 QR/ETfUW5uvOr4rqMcyMCxg3yhc/QvYV67LFMrLusJ1IlCBhcfAC4r2B91sECHXr fJvdfGwL6HBt3tAJ5zxXZjTEwiFc77TGxswbt4lQplhFqTHfi/ZovGUiS/W3nQl6 vX0zFtoYLTRAK0KtCNiP =JRkZ -----END PGP SIGNATURE-----

Feb. 20, 2015

Re: [PATCH 3/3] dwrite/tests: Test default colors of render target memory HDC

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11640 Your paranoid android. === build (build) === Patch failed to apply

Feb. 20, 2015