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

Re: [PATCH 6/7] dxgi: Store parents in textures.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-31 um 13:01 schrieb Henri Verbeet: > I don't get what this patch is trying to achieve. For one, the > description doesn't quite seem to match what it does. As it is, it > looks like an odd mix of making it harder to get at the d3d11 > texture from the wined3d surface and some bits that should have > been in an earlier patch. The idea of this patch and the next one is to avoid using wined3d_surface in dxgi and friends. So yeah, it makes it harder to get the d3d11 texture from the wined3d surface because it won't be necessary to do that any more. The way I split the patches seems reasonable to me to avoid making too many changes at once. (There's one more use of wined3d_surface left in d3d11, but this just temporarily gets the surface to call wined3d_surface_map and doesn't store it anywhere). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV5DfIAAoJEN0/YqbEcdMw2hIP+QGO2s7ECuBYXygQgtO80Cwn k6MWscKv5BiRTzsq/r7sVcvNkXXM2uDxcocsvSmD89qzG7FmRErxuVNohj9XNdk4 esQnxANlH5qfKduooaIqAlm/QKuElZiBJQHYJEVkKQeuHzT7Gu1ajilDLwAa0tP0 reVLufI0/K8IeeKsA4ErJm4W6CwbOoscTwZ+rxU6Nq6iXE3teNqtxZBGtMt1gtOn 47wFpLK35PM4axdlCQ6TMce2iccgUebEv5eN2WiZLzYZjtFAurFBVteTHfLROojz X24J6wEGHmdtrh8+E9eVahKKKWTgvVwD/J0T8vcEPJVrkMr4Rp/cg+hX3DNCo4qp niqk7J/QAb2Gk67LhVyoDviJ8xNOJvZ7haQo8AdohJ+DHLYMvD2oWZcpR6vpt9O4 gLg1tLAWoVyiEOD+NeAYH52mDOM2lWH0x5L+WeCbtOaqLx1/UTn5+GRrzBQfEs1b ACigpZ+x2CUwTfiWfuoiZGrfoLC8rWWErlFcWRK4oT2AoP47V7I32qijv93NccUX FXpZUgDjBNRCBnw0sO5n8GYYMb9DKWYbzrex/SyTXpHWNFlexyuACGgWLz+Mq+YK TI5Yf3pShP+K8ifPCySNP0Z208M0BM8quvlJ7BfhLSp3iXxuR/W+a4nENy8fsWiR jPPlGyvWqREtq4eg925y =g+20 -----END PGP SIGNATURE-----

Aug. 31, 2015

Re: [PATCH 6/7] dxgi: Store parents in textures.

by Henri Verbeet

On 31 August 2015 at 00:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2875,7 +2875,7 @@ static HRESULT CDECL device_parent_surface_created(struct wined3d_device_parent > TRACE("device_parent %p, container_parent %p, surface %p, parent %p, parent_ops %p.\n", > device_parent, container_parent, surface, parent, parent_ops); > > - *parent = container_parent; > + *parent = NULL; > *parent_ops = &d3d10_null_wined3d_parent_ops; > > return S_OK; I don't get what this patch is trying to achieve. For one, the description doesn't quite seem to match what it does. As it is, it looks like an odd mix of making it harder to get at the d3d11 texture from the wined3d surface and some bits that should have been in an earlier patch.

Aug. 31, 2015

Re: [PATCH 2/7] wined3d: Return a texture from wined3d_swapchain_get_back_buffer.

by Henri Verbeet

On 31 August 2015 at 00:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + wined3d_surface = wined3d_surface_from_resource(wined3d_resource); > surface_impl = wined3d_surface_get_parent(wined3d_surface); This works, but it's a bit silly. You can just use wined3d_resource_get_parent(). > diff --git a/dlls/dxgi/swapchain.c b/dlls/dxgi/swapchain.c > index ce09450..cfc1a09 100644 > --- a/dlls/dxgi/swapchain.c > +++ b/dlls/dxgi/swapchain.c > @@ -152,13 +154,15 @@ static HRESULT STDMETHODCALLTYPE dxgi_swapchain_GetBuffer(IDXGISwapChain *iface, > > EnterCriticalSection(&dxgi_cs); > > - if (!(backbuffer = wined3d_swapchain_get_back_buffer(This->wined3d_swapchain, > + if (!(texture = wined3d_swapchain_get_back_buffer(This->wined3d_swapchain, > buffer_idx, WINED3D_BACKBUFFER_TYPE_MONO))) > { > LeaveCriticalSection(&dxgi_cs); > return DXGI_ERROR_INVALID_CALL; > } > > + resource = wined3d_texture_get_sub_resource(texture, 0); > + backbuffer = wined3d_surface_from_resource(resource); > parent = wined3d_surface_get_parent(backbuffer); > hr = IUnknown_QueryInterface(parent, riid, surface); > LeaveCriticalSection(&dxgi_cs); And here you don't even need the sub-resource, because you want the (d3d11) texture in the first place. I.e., you can just use wined3d_texture_get_parent().

Aug. 31, 2015

Re: mciavi32: Add partial support for MCI_DGV_PLAY_REPEAT

by Bruno Jesus

On Monday, August 31, 2015, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Bruno, > > >If you ever have time, please take a look. > + wma->dwCurrVideoFrame = wma->dwCurrAudioBlock = 0; > I'm sorry I'd reject this patch because it's missing integration for the > MCI_FROM keyword. > > Example using MS' clock.avi: > OPEN clock.avi alias c > WINDOW c State Show ; may still be needed in Wine > PLAY c FROM 2 TO 5 repeat > should open the window and repeat stepping the clock from 3 to 6 o'clock. > (You remember my MCI shell in bugzilla, don't you?) > > You could argue that there's no need to bother for MCI_FROM, because it's > not yet supported with audio output (see mmoutput.c). However, play c FROM > x to y currently works with video only output (e.g. clock.avi), thus new > patches should at least support what's already in place. > > BTW (not in your patch): > FIXME("Should recompute dwCurrAudioBlock, except unsynchronized > sound & video\n"); > Typo, should be "expect" > > Supporting sound with MCI_FROM non-zero would be the matter of another > patch for a volunteer... > > In summary, I believe that a better patch would either add > dwFromVideoFrame to WINE_MCIAVI or remember dwCurrentVideoFrame (but see > below) at the entrance of MCIAVI_Player and use that. > > Note that I'd expect any patch to handle this scenario correctly: > Play c FROM 2 TO 5 repeat > Play c TO 8 repeat > In native, the second play would *continue* playing from the current > position upto 9 o'clock, then resume from 0 (not 3 o'clock, because 0 is > the default FROM value in the second play command). > > Well, that's probably too much for a single patch, since it would likely > require keeping the player thread alive, just changing its start/repeat and > end positions, rather than restarting a new one. Thank you very much for your review, i knew you would be interested. I did use the mcishell to test with other avi files. I'll try to address the issues mentioned and resend, I was not aware of the from argument.

Aug. 31, 2015

Re: [PATCH] dxgi/tests: Avoid c++ style comment.

by Stefan Dösinger

> Am 31.08.2015 um 00:21 schrieb Stefan Dösinger <stefandoesinger(a)gmail.com>: > > better to remove those index comments entirely. While they may > seem useful on first sight, it's easy for them to become misleading if > lines are added / removed / commented out. I'll send my patch, then > Henri can chose whatever he likes best. Hmm, somehow a part of the first sentence got lost, but I think the mail still conveys the message I wanted to send.

Aug. 31, 2015

Re: po: Update German translation.

by Julian Rüger

Hi Florian, I omitted the hyphen on purpose (for consistency). There are a few other instances of "Wine foo" without hyphen, and even: #: uninstaller.rc:29 msgid "Wine Application Uninstaller" msgstr "Wine Anwendungsentferner" I think this is a kind of 50-50 case, where it's okay either way. Am Freitag, den 28.08.2015, 15:07 +0200 schrieb Florian Pelz: > Sorry for sending to the wrong list. > > On 08/28/2015 03:03 PM, Florian Pelz wrote: > > On 08/28/2015 02:35 PM, Julian Rüger wrote: > >> +"Wine Anwendungsentferner\n" > > > > This needs a hyphen ("Wine-Anwendungsentferner\n"). > > >

Aug. 31, 2015

Re: mciavi32: Add partial support for MCI_DGV_PLAY_REPEAT

by Joerg-Cyril.Hoehle＠t-systems.com

Bruno, >If you ever have time, please take a look. + wma->dwCurrVideoFrame = wma->dwCurrAudioBlock = 0; I'm sorry I'd reject this patch because it's missing integration for the MCI_FROM keyword. Example using MS' clock.avi: OPEN clock.avi alias c WINDOW c State Show ; may still be needed in Wine PLAY c FROM 2 TO 5 repeat should open the window and repeat stepping the clock from 3 to 6 o'clock. (You remember my MCI shell in bugzilla, don't you?) You could argue that there's no need to bother for MCI_FROM, because it's not yet supported with audio output (see mmoutput.c). However, play c FROM x to y currently works with video only output (e.g. clock.avi), thus new patches should at least support what's already in place. BTW (not in your patch): FIXME("Should recompute dwCurrAudioBlock, except unsynchronized sound & video\n"); Typo, should be "expect" Supporting sound with MCI_FROM non-zero would be the matter of another patch for a volunteer... In summary, I believe that a better patch would either add dwFromVideoFrame to WINE_MCIAVI or remember dwCurrentVideoFrame (but see below) at the entrance of MCIAVI_Player and use that. Note that I'd expect any patch to handle this scenario correctly: Play c FROM 2 TO 5 repeat Play c TO 8 repeat In native, the second play would *continue* playing from the current position upto 9 o'clock, then resume from 0 (not 3 o'clock, because 0 is the default FROM value in the second play command). Well, that's probably too much for a single patch, since it would likely require keeping the player thread alive, just changing its start/repeat and end positions, rather than restarting a new one. Regards, Jörg Höhle

Aug. 31, 2015

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible

by Piotr Caban

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

Aug. 31, 2015

Re: [PATCH 5/7] d3d8/tests: Add more GetBackBuffer error handling tests.

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=16429 Your paranoid android. === w8 (32 bit device) === device.c:1225: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1270: Test failed: Reset failed, hr 0x88760868. device.c:1272: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1276: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1283: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1284: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1285: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1286: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1287: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1288: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1293: Test failed: Screen width is 640, expected 800. device.c:1294: Test failed: Screen height is 480, expected 600. device.c:1300: Test failed: Back buffer width is 640, expected 800. device.c:1302: Test failed: Back buffer height is 480, expected 600. device.c:1332: Test failed: Screen width is 640, expected 1024. device.c:1333: Test failed: Screen height is 480, expected 768. device.c:2580: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2585: Test failed: The focus window is active. device.c:2593: Test failed: Got unexpected hr 0x88760869. device.c:2599: Test failed: Got unexpect screen size 800x600. device.c:2614: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2623: Test failed: Got unexpect screen size 800x600. device.c:2636: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2644: Test failed: Got unexpect width 640. device.c:2645: Test failed: Got unexpect height 480.

Aug. 31, 2015

Re: [PATCH 2/2] gdi32: Added GetFontRealizationInfo() export

by Nikolay Sivov

On 29.08.2015 21:19, Marvin wrote: > 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=16404 > > Your paranoid android. > > > === wvistau64 (64 bit font) === > The test timed out > > Looks random, just ran it manually and it worked - http://testbot.winehq.org/JobDetails.pl?Key=16432 (64 bit tests)

Aug. 31, 2015