October 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] d3d8/tests: Add a small test for multisampled CopyRects().

by Francois Gouget

commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Oct 19 22:03:11 2011 +0200 d3d8/tests: Add a small test for multisampled CopyRects(). This commit causes the d3d8:visual to crash on my desktop (Debian Testing, 9600GT, 285.05.09-1 proprietary driver): wine: Unhandled stack overflow at address 0x7e3ab8bf (thread 0009), starting debugger... err:seh:setup_exception_record stack overflow 1100 bytes in thread 0009 eip 7ef8952b esp 00240ee4 stack 0x240000-0x241000-0x340000 The call that causes the crash is: hr = IDirect3DDevice8_CopyRects(device, rt, NULL, 0, readback, NULL); The stack trace seems to point towards an out of hand recursion problem that eventually causes a stack overrun: Backtrace: =>0 0x7e3a7a32 d3dfmt_get_conv+0x12(surface=0x161728, need_alpha_ck=0x1, use_texturing=0x1, format=0x242074, convert=0x24210c) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:4372] in wined3d (0x00242018) 1 0x7e3b05ee surface_load_texture+0xcd(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5953] in wined3d (0x00242128) 2 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242258) 3 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242388) 4 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242498) 5 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x002425c8) 6 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002426f8) 7 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242808) 8 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242938) 9 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242a68) 10 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242b78) 11 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242ca8) 12 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242dd8) 13 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242ee8) 14 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243018) 15 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00243148) 16 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00243258) 17 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243388) 18 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002434b8) 19 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x002435c8) [...] -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

Oct. 25, 2011

D3DXCreatePolygon

by David Adam

Any problem with my D3DXCreatePolygon patch? Thanks in advance. David

Oct. 25, 2011

D3DXCreatePolygon

by paulo lesgaz

Hello, any problem with my D3DXCreatePolygon patch? Thanks in advance. David

Oct. 25, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Alexandre Julliard

Thomas Faber <thfabba(a)gmx.de> writes: > it is not a workaround. It is the current riched20 code that relies on the bug > being present (hence why it asserts on Windows). > The patch makes it work with a _correctly working_ version of > GetTextExtentExPointW (and also with the current one). > You could see it as a prerequisite to fixing that bug (that is, to fixing it > without breaking richedit controls). Ah OK, it's fine then. Thanks. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Thomas Faber

Hey, On 2011-10-24 20:03, Alexandre Julliard wrote: > Thomas Faber <thfabba(a)gmx.de> writes: > >> Windows's version of GetTextExtentExPointW, which is called in that function, >> returns a value of 1 in this case (Wine's does not, which would appear to be >> a bug), leading to the "i<len" assertion failure if there is no text in the >> control. >> The patch fixes riched20 to correctly handle either behavior by >> adding a fast path for cx <= 0 (the function obviously needs to return 0 in >> the cx == 0 case too, so it can skip the calculation). > > You should not be adding workarounds for Wine bugs, the bugs need to be > fixed instead. > it is not a workaround. It is the current riched20 code that relies on the bug being present (hence why it asserts on Windows). The patch makes it work with a _correctly working_ version of GetTextExtentExPointW (and also with the current one). You could see it as a prerequisite to fixing that bug (that is, to fixing it without breaking richedit controls). Regards, Tom

Oct. 24, 2011

Re: riched20: explicitly cast WPARAM to character types

by Thomas Faber

Hi Michael, On 2011-10-23 21:25, Michael Stefaniuc wrote: > On 10/22/2011 10:38 PM, Thomas Faber wrote: >> This makes the use of casts more consistent and shows the conversion >> from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. >> Also fixes two MSVC warnings. > To make it consistent remove the WCHAR cast 3 lines above. > Casts are *not* there to show a conversion is intentional. They tell the > compiler to STFU and to the human reader they mean "*WARNING* doing > something odd here". So don't cry wolf when there's no wolf in sight. > > No clue anyway why MSVC even warns, integer to integer conversions are > allowed. If you still want to get rid of those warnings the fix would be > to change the type of charCode to WCHAR. To correctly unmarshal the > WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). good point, that sounds like a more appropriate solution. I'll see to it when I find the time. Thanks. -Tom

Oct. 24, 2011

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]

by Alexandre Julliard

Thomas Faber <thfabba(a)gmx.de> writes: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. > The patch fixes riched20 to correctly handle either behavior by > adding a fast path for cx <= 0 (the function obviously needs to return 0 in > the cx == 0 case too, so it can skip the calculation). You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2011

Re: [PATCH 4/5] wined3d: Refuse to create a D3D10 wined3d device if it is not supported by the GPU.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (wined3d->dxVersion >= 10 && (shader_caps.VertexShaderVersion < WINED3DVS_VERSION(4,0) > + || shader_caps.PixelShaderVersion < WINED3DPS_VERSION(4,0))) This should probably be handled in dxgi_device_init().

Oct. 24, 2011

Re: [PATCH 2/5] d3d9: Limit VS/PS reported version.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(3,0)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(3,0); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(3,0)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(3,0); > + This should probably go into filter_caps().

Oct. 24, 2011

Re: [PATCH 1/5] d3d8: Limit VS/PS reported version.

by Henri Verbeet

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4); > + fixup_caps() should already do this.

Oct. 24, 2011