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

Re: [PATCHv4 2/3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting
by Henri Verbeet Feb. 17, 2014

Feb. 17, 2014

On 13 February 2014 13:05, Martin Storsjo <martin(a)martin.st> wrote: > static HRESULT arbfp_blit_alloc(struct wined3d_device *device) > { > + struct arbfp_blit_priv *priv; > device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); > if(!device->blit_priv) { > ERR("Out of memory\n"); > return E_OUTOFMEMORY; > } > + priv = device->blit_priv; > + > + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) > + { > + ERR("Failed to initialize rbtree.\n"); > + HeapFree(GetProcessHeap(), 0, device->blit_priv); > + device->blit_priv = NULL; > + return E_OUTOFMEMORY; > + } > + > return WINED3D_OK; > } > The following is probably slightly nicer: static HRESULT arbfp_blit_alloc(struct wined3d_device *device) { - device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); - if(!device->blit_priv) { - ERR("Out of memory\n"); + struct arbfp_blit_priv *priv; + + if (!(priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*priv)))) return E_OUTOFMEMORY; + + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) + { + ERR("Failed to initialize rbtree.\n"); + HeapFree(GetProcessHeap(), 0, priv); + return E_FAIL; } + + device->blit_priv = priv; + return WINED3D_OK; } > + if (desc) > + HeapFree(GetProcessHeap(), 0, desc); There's no point in checking for NULL before HeapFree(). Perhaps more importantly, I think it makes more sense to insert the rbtree entries in arbfp_blit_set(), instead of duplicating the code between gen_p8_shader() and gen_yuv_shader().

4 5

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts
by Henri Verbeet Feb. 17, 2014

Feb. 17, 2014

On 13 February 2014 14:52, Martin Storsjo <martin(a)martin.st> wrote: > + IDirect3DSurface9 *surface = NULL, *target = NULL; You don't need those to be NULL. > + HRESULT color; You'll want to use D3DCOLOR instead of HRESULT here. > + /* Some (all?) Windows drivers do not support YUV 3D textures, only 2D surfaces in > + * StretchRect. Thus use StretchRect to draw the YUV surface onto the screen instead > + * of drawPrimitive. */ > + if (IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0, > + D3DRTYPE_SURFACE, format) != D3D_OK) > + { > + skip("%s is not supported.\n", fmt_string); > + continue; > + } You should also verify the StretchRect() is supported with CheckDeviceFormatConversion(). > + BYTE Y = (color >> 16) & 0xff; > + BYTE U = (color >> 8) & 0xff; > + BYTE V = (color >> 0) & 0xff; It's probably just as easy to just store the separate components to begin with. > + hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT); > + ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr); > + > + /* Native D3D can't resist filtering the YUY surface, even though we asked it not to > + * do so above. To prevent running into precision problems, read at points with some > + * margin within the rect. */ That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.

3 2

Re: dpnet: Implement IDirectPlay8Client Initialize (try 3)
by Marvin Feb. 17, 2014

Feb. 17, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4945 Your paranoid android. === w8 (32 bit client) === Timeout

3 4

d3d bisecting help needed
by Stefan Dösinger Feb. 17, 2014

Feb. 17, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, If anyone wants to help me out with a d3d performance issue here's your chance: My regression tests picked up a performance drop on r300g a few weeks ago: http://openbenchmarking.org/result/1402162-STEF-WINE17135&track_view=60 . Read graphs right to left. The regression can be seen in the following tests: drawprim_d3d (a simple draw overhead tester), Half Life 2 and Trackmania Nations. According to the test data, the regression happened between wine-1.7.10-73-g460991a and wine-1.7.10-112-g81c42ce. I do not know if the regression is in Wine or Mesa. Unfortunately my test setup does not track which Mesa revision was used for each test, but usually the date of the used mesa commit matches the date of the Wine commit. What you'll need is a GPU supported by the Mesa r300g driver, a setup where you can use Mesa from git and of course a working Wine build setup. You'll also need one of the games in question. The drawprim_d3d microbenchmark can be found at https://84.112.174.163/~stefan/pts/drawprim_d3d.exe , but the server may be down over the next few days. If the download does not work just mail me and I'll send you the .exe. Thanks, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTAfoRAAoJEN0/YqbEcdMwhZsP/0iLEUg0B/KJ2bJdwtFX/DBg IamXt8oACRNpyMqVnEjmynxKOflomeo8rqELK46j0NhCeGzTNJaPzRgLrQ4L3w/0 5atPd/OnWIBRhoD06vXp1vCn5/EgqDqmU+U84bmbJev9lkhd1rLWqt3uHl8tWjxL VPphPbcriUCXhYjmaXdSD12oKJXYaLclYEXXTOjktFvSck18dfiohvypCHPDBlxp oGhFV/B4NtqHXy62O+vztIA+wisDbBtGUfni4WIdCX82H1kE9rEcpj6zhS638IHp xbiWtVsBYzYHqw6VVGUql2JipkYXTnrKBju7BQetd93KSJHFWnn4TdeOI3ggsAnU oQNR5lKmkG/PWVsMi23lVsZVrCmIau8BgSQQLWZgRUdJEHhj1+6hehabUNJVc49q TFhsSDxcNhbv3bLYrmJFhfQWQTFis/iGYcIRWqX+590ycaUEJmEmi5JsdcVdsxRv IlAhPXbAo1rZv/815ZBX4l8QdJecHiHyewhN74O6wG7EzGZaChLhP0dIuHRc6q9g EuICi7CYDrzv047vXELwePqxAkgQva6/JWd8GvzvVbh971qvWKMlB90p3HEHf42L WzB+bpXd1qsxfeXcbC2Cw2iTJWyjUoY1Zs1wbNEUgFXeIyjDYIkCXD1ADLOQqbJB mtimRynrUbtS9TJWwM4W =Z4Pf -----END PGP SIGNATURE-----

1 0

Re: [PATCH] comctl32/tests: Some tests for Button control
by Dmitry Timoshkov Feb. 17, 2014

Feb. 17, 2014

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > --- /dev/null > +++ b/dlls/comctl32/tests/button.c > @@ -0,0 +1,811 @@ > +/* Unit test suite for Button control. > + * > + * Copyright 2014 Nikolay Sivov for CodeWeavers > + * If I read this patch correctly this is just a copy of button tests from user32, and in that case please add all copyright notices from that file, or just the authors of the copied code. -- Dmitry.

2 1

Re: dpnet: Implement IDirectPlay8Client Initialize (try 2)
by Marvin Feb. 17, 2014

Feb. 17, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4942 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

1 0

Re: dpnet: Implement IDirectPlay8Client Initialize
by Marvin Feb. 16, 2014

Feb. 16, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4941 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: Assorted spelling fixes
by Dmitry Timoshkov Feb. 16, 2014

Feb. 16, 2014

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > - cab_ULONG window_size; /* window size (1Kb through 2Mb) */ > + cab_ULONG window_size; /* window size (1 KB through 2 MB) */ This is not the typos, that's a common way of writing sizes by programmers, personally I prefer the old form (and will keep using it in future) and hate the "fixed" variant. Please avoid this kind of "fixes". -- Dmitry.

4 7

Gifting steam/gog games to Wine developers
by Jerome Leclanche Feb. 16, 2014

Feb. 16, 2014

Hi list I was reading a bug which gave me an idea. I have a lot of unused Steam gift links from duplicates in my Humble Bundle purchases. I'd like to share those with whomever needs any of them to work on bugs (or to Wine devs who want them, you guys more than deserve them). I'd like to set up a Wiki page containing a list of available games and a point of contact to get it gifted, encouraging other Wine users to do the same and have one more open method of contributing to the project. Is this something that would interest anyone? J. Leclanche

4 4

Re: [PATCH 5/5] ddraw/tests: Port test_private_data to ddraw4.
by Marvin Feb. 16, 2014

Feb. 16, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4935 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3185: Test failed: SetDisplayMode failed, hr 0x80004001. === w8 (32 bit ddraw4) === ddraw4.c:3462: Test failed: SetDisplayMode failed, hr 0x80004001.

1 0

Re: configure: Add import library for xmllite.
by Henri Verbeet Feb. 16, 2014

Feb. 16, 2014

On 14 February 2014 08:23, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > -WINE_CONFIG_DLL(xmllite) > +WINE_CONFIG_DLL(xmllite,,[implib]) That's auto-generated by make_makefiles from Makefile.in.

2 2

Re: [PATCH 4/5] d3d8/tests: Add a test for sub resource private data.
by Marvin Feb. 16, 2014

Feb. 16, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4934 Your paranoid android. === w8 (32 bit device) === device.c:2572: Test failed: Expected foreground window 00030196, got 0002004E. device.c:3268: Test failed: Expected wndproc 0x410530, got 0x410530.

1 0

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test (try 2).
by Marvin Feb. 16, 2014

Feb. 16, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4931 Your paranoid android. === w8 (32 bit visual) === visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x00000000: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xff000000: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 1/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x00ff0000: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x0000ff00: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x000000ff: Got color 0x00000000 for pixel 2/1, expected 0x00008700, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 1/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xffff0000: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xff00ff00: Got color 0x00000000 for pixel 2/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xff0000ff: Got color 0x00000000 for pixel 2/1, expected 0x00b30000, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 1/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x00ffff00: Got color 0x00000000 for pixel 2/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 1/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x00ff00ff: Got color 0x00000000 for pixel 2/1, expected 0x004bff1c, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 1/1, expected 0x004bffff, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x0000ffff: Got color 0x00000000 for pixel 2/1, expected 0x000030e1, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 1/1, expected 0x00b300e1, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xffffff00: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 1/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xffff00ff: Got color 0x00000000 for pixel 2/1, expected 0x00ffd01c, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 1/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xffffffff: Got color 0x00000000 for pixel 2/1, expected 0x00ff79ff, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 1/1, expected 0x000b8b00, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x4cff4c54: Got color 0x00000000 for pixel 2/1, expected 0x00b6ffa3, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 1/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x00800080: Got color 0x00000000 for pixel 2/1, expected 0x0000ff00, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 1/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0xff80ff80: Got color 0x00000000 for pixel 2/1, expected 0x00ff00ff, format D3DFMT_YUY2. visual.c:10473: Test failed: Failed to draw surface onto backbuffer, hr 0x8876086c. visual.c:10482: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 1/1, expected 0x006dff45, format D3DFMT_YUY2. visual.c:10486: Test failed: Input 0x1c6b1cff: Got color 0x00000000 for pixel 2/1, expected 0x0000d500, format D3DFMT_YUY2.

1 0

FOSDEM - Videos now watchable
by Marcus Meissner Feb. 16, 2014

Feb. 16, 2014

Hi, The FOSDEM Videos have been uploaded with correct sound again. http://wiki.winehq.org/FOSDEM2014 has our index. Or more direct links: http://video.fosdem.org/2014/AW1120/Sunday/ If you have not uploaded your slides, please do :) Ciao, Marcus

1 0

(no subject)
by Jarkko Korpi Feb. 16, 2014

Feb. 16, 2014

I had similar gifting idea before, we should use steam discount sales for gifting games for wine devs.

1 0

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.
by Henri Verbeet Feb. 16, 2014

Feb. 16, 2014

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Unfortunately different implementations(Windows-NV and Mac-AMD tested) interpret some colors vastly > + * differently, so we need a max diff of 18. */ And actually, is there any chance the "vastly differently" here is because of using BT.601 vs. BT.709 coefficients, or not including the headroom/footroom scaling + offsets?

2 1

Questions about filename_tests in dlls/shell32/tests/shlexec.c
by Zhenbo Li Feb. 16, 2014

Feb. 16, 2014

Hello, I checked wine test errors, and found some errors for dlls/shell32/tests/shlexec.c[1]. I wanted to fix bugs in 'static void test_filename(void)'. However, I can't understand the intention of previous code: All testcases are put into 'static filename_tests_t filename_tests[]', then they are tested via a while-loop. I think it is difficult to locate *which* testcase really fails. Is re-factoring such code encouraged? If so, I'm glad to do it. I really appreciate all finds of ideas. Thank you. [1]: http://test.winehq.org/data/aa22a3c4b2e772636163ea50e7245dba01fe7b34/win8_n… Zhenbo Li

3 2

Re: Assorted spelling fixes
by Marvin Feb. 15, 2014

Feb. 15, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=4916 Your paranoid android. === w8 (32 bit midi) === midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:518: Test failed: midiOutPrepare old size rc=MMSYSERR_INVALPARAM midi.c:519: Test failed: MHDR.dwFlags when prepared 0 midi.c:523: Test failed: midiStreamOut old size rc=MIDIERR_UNPREPARED midi.c:547: Test failed: MHDR.dwFlags 0 no ISSTRM when out of queue midi.c:553: Test failed: MHDR.dwFlags 0 not DONE when out of queue midi.c:554: Test failed: Wait failed: 0102 -559038737 midi.c:554: Test failed: Expect message 3ca from midiStream callback midi.c:555: Test failed: Wait failed: 0102 -559038737 midi.c:555: Test failed: Expect message 3c9 from midiStreamOut midi.c:558: Test failed: play left MIDIHDR.dwOffset at 1234567890 midi.c:561: Test failed: midiOutUnprepare rc=MMSYSERR_INVALPARAM midi.c:563: Test failed: midiOutUnprepare #2 rc=MMSYSERR_INVALPARAM midi.c:566: Test failed: MHDR.dwFlags when done 0 midi.c:580: Test failed: stream set tempo 500000 midi.c:588: Test failed: midiOutPrepare used flags 8 rc=MMSYSERR_INVALPARAM midi.c:590: Test failed: midiOutUnprepare used flags 8 rc=MMSYSERR_INVALPARAM

1 0

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)
by Henri Verbeet Feb. 15, 2014

Feb. 15, 2014

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) > +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) This doesn't need "gl_info" either anymore now. It's also a bit questionable if context_restore_gl_context() has much of a purpose at all anymore, it's pretty much just a wglMakeCurrent() call, and has only two callers.

2 2

Converting source to unicode, bug 28189
by Hugh McMaster Feb. 14, 2014

Feb. 14, 2014

I've put together a draft patch to address bug 28189, regsvr32: No usage in wineconsole. I'm using resource strings and have converted all of the printf calls to WriteConsoleW. I also converted the source to Unicode, but overall, there are few coding points I'm not quite sure about. If someone could look over the changes and offer some feedback, I'd certainly appreciate it. URL: http://bugs.winehq.org/show_bug.cgi?id=28189 -- Hugh

2 4

Re: xmllite: Don't fail the whole parsing process because of unsupported 'xmlns' attribute.
by Nikolay Sivov Feb. 14, 2014

Feb. 14, 2014

On 2/14/2014 11:23, Dmitry Timoshkov wrote: > This patch allows to successfully parse pretty complex XML task definitions. > > Please apply after other xmllite fixes. I think it's fine to relax a check here as you did if it really helps. Same applies to other patches. My main problem with all of that is that whole reader code needs to be revised and partially rewritten at some point (better sooner than later), to properly support chunked reads and corresponding state updates. Looking at it now I don't actually like the way I did it, it's not easily extensible and not very clean. Do you plan to add more code to xmllite itself or what we have is enough for taskschd so far?

2 1

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.
by Henri Verbeet Feb. 14, 2014

Feb. 14, 2014

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - HRESULT color; > - DWORD ref_color_left, ref_color_right; > + DWORD ref_color_left, ref_color_right, color; > If you're cleaning it up anyway, you may as well make that a D3DCOLOR. > + static const struct > + { > + DWORD in; /* The input color. */ > + DWORD uyvy_left; /* "in" interpreted as uyvy and transformed to RGB, pixel 1/1. */ > + DWORD uyvy_right; /* "in" interpreted as uyvy and transformed to RGB, pixel 2/1. */ > + DWORD yuy2_left; /* "in" interpreted as yuy2 and transformed to RGB, pixel 1/1. */ > + DWORD yuy2_right; /* "in" interpreted as yuy2 and transformed to RGB, pixel 2/1. */ > + } > + test_data[] = > + { > + {0x00000000, 0x00008700, 0x00008700, 0x00008700, 0x00008700}, > + {0xff000000, 0x00008700, 0x004bff1c, 0x00b30000, 0x00b30000}, > + {0x00ff0000, 0x00b30000, 0x00b30000, 0x00008700, 0x004bff1c}, > + {0x0000ff00, 0x004bff1c, 0x00008700, 0x000030e1, 0x000030e1}, > + {0x000000ff, 0x000030e1, 0x000030e1, 0x004bff1c, 0x00008700}, > + {0xffff0000, 0x00b30000, 0x00ffd01c, 0x00b30000, 0x00ffd01c}, > + {0xff00ff00, 0x004bff1c, 0x004bff1c, 0x00b300e1, 0x00b300e1}, > + {0xff0000ff, 0x000030e1, 0x004bffff, 0x00ffd01c, 0x00b30000}, > + {0x00ffff00, 0x00ffd01c, 0x00b30000, 0x000030e1, 0x004bffff}, > + {0x00ff00ff, 0x00b300e1, 0x00b300e1, 0x004bff1c, 0x004bff1c}, > + {0x0000ffff, 0x004bffff, 0x000030e1, 0x004bffff, 0x000030e1}, > + {0xffffff00, 0x00ffd01c, 0x00ffd01c, 0x00b300e1, 0x00ff79ff}, > + {0xffff00ff, 0x00b300e1, 0x00ff79ff, 0x00ffd01c, 0x00ffd01c}, > + {0xffffffff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff}, > + {0x4cff4c54, 0x00ff0000, 0x00ff0000, 0x000b8b00, 0x00b6ffa3}, > + {0x00800080, 0x00000000, 0x00000000, 0x0000ff00, 0x0000ff00}, > + {0xff80ff80, 0x00ffffff, 0x00ffffff, 0x00ff00ff, 0x00ff00ff}, > + {0x1c6b1cff, 0x000000fd, 0x000000fd, 0x006dff45, 0x0000d500}, > }; ... > - for(fmt = 0; fmt < 2; fmt++) { > - if(fmt == 0) { > - format = D3DFMT_UYVY; > - fmt_string = "D3DFMT_UYVY"; > - } else { > + for (fmt = 0; fmt < 2; fmt++) > + { > + if (fmt) > + { > format = D3DFMT_YUY2; > fmt_string = "D3DFMT_YUY2"; > } > + else > + { > + format = D3DFMT_UYVY; > + fmt_string = "D3DFMT_UYVY"; > + } ... > + if (fmt) > + { > ref_color_left = test_data[i].yuy2_left; > ref_color_right = test_data[i].yuy2_right; > } > + else > + { > + ref_color_left = test_data[i].uyvy_left; > + ref_color_right = test_data[i].uyvy_right; > + } > There's probably a nicer way to do all that.

1 0

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.
by Henri Verbeet Feb. 14, 2014

Feb. 14, 2014

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

1 0

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.
by Henri Verbeet Feb. 14, 2014

Feb. 14, 2014

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

1 0

Re: [PATCH 5/5] d3dx9: Handle pixel formats larger than 32 bits in surface loading / filtering functions.
by Henri Verbeet Feb. 14, 2014

Feb. 14, 2014

On 14 February 2014 15:53, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (format->bits[c]) > + { > + mask = format->bits[c] == 32 ? ~0U : (1 << format->bits[c]) - 1; You could probably also do that as "mask = ~0u >> (32 - format->bits[c]);", since you already need to check "format->bits[c]" for 0 anyway.

2 1