October 2015 - Wine-devel - list.winehq.org

Re: mshtml: Fixed some tests on win10.
by Marvin 13 Oct '15

13 Oct '15

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=17332 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3559: Test failed: unexpected call IsErrorUrl htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc} htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc} htmldoc.c:2877: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2877: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc} === w1064 (64 bit htmldoc) === htmldoc.c:3559: Test failed: unexpected call IsErrorUrl htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc} htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc} htmldoc.c:2877: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2877: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:875: Test failed: unexpected call {ede9319b-a823-403d-bd14-14c8adfe67dc}

1 0

Re: [PATCH 2/5] wined3d: Pass a context to read_from_framebuffer.
by Matteo Bruni 13 Oct '15

13 Oct '15

2015-10-12 22:34 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>: > Sometimes the context won't be reusable because we need a specific > context to access the WGL drawable. Afterwards we need to switch back to > the caller's context. Bug 34574 is related to this. This is only > relevant for backbuffer offscreen rendering, and in practise it is rare. > It'll only matter if the application is blitting from an onscreen > surface to a currently active offscreen one. For everything else the > offscreen surface is copied into the texture when it is deactivated. > > Note that in most cases the wined3d_context * structure is the same for > both surfaces involved in the blit, but context->render_offscreen > differs for source and destination. That's why context_restore needs a > surface and not the old context. > > I'm open to placing the extra context_acquire / context_release calls > into the callers. We need them in 4 places: read_from_framebuffer, > surface_blt_to_drawable, surface_blt_fbo and surface_load_fb_texture. Yes, IMHO that would be better, although I haven't actually tried that so it might turn out to be bad in practice. Obviously ignore this suggestion altogether if Henri thinks otherwise :P

2 2

Re: [PATCH 4/5] wined3d: Pass a context to surface_load_drawable.
by Matteo Bruni 13 Oct '15

13 Oct '15

2015-10-12 22:34 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>: > Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> > --- > dlls/wined3d/surface.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index f5ee7e1..c70b709 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3850,11 +3850,11 @@ static void surface_load_sysmem(struct wined3d_surface *surface, > surface, wined3d_debug_location(surface->locations)); > } > > +/* Context activation is done by the caller. */ > static HRESULT surface_load_drawable(struct wined3d_surface *surface, > - const struct wined3d_gl_info *gl_info) > + struct wined3d_context *context) > { > RECT r; > - struct wined3d_context *context; > > if (wined3d_settings.offscreen_rendering_mode == ORM_FBO > && wined3d_resource_is_offscreen(&surface->container->resource)) > @@ -3863,12 +3863,10 @@ static HRESULT surface_load_drawable(struct wined3d_surface *surface, > return WINED3DERR_INVALIDCALL; > } > > - context = context_acquire(surface->resource.device, surface); > surface_get_rect(surface, NULL, &r); > surface_load_location(surface, WINED3D_LOCATION_TEXTURE_RGB); > surface_blt_to_drawable(surface->resource.device, context, > WINED3D_TEXF_POINT, FALSE, surface, &r, surface, &r); > - context_release(context); > > return WINED3D_OK; > } > @@ -4125,7 +4123,10 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location) > break; > > case WINED3D_LOCATION_DRAWABLE: > - if (FAILED(hr = surface_load_drawable(surface, gl_info))) > + context = context_acquire(device, NULL); > + hr = surface_load_drawable(surface, context); Doesn't this context_acquire() need to take the surface of the drawable into account (i.e. something like the context_acquire you're removing from surface_load_drawable())? Maybe the context is already guaranteed to be correct? If that's the case though perhaps a comment would help since it's not immediately obvious.

2 2

Re: [PATCH] advapi32/tests: Simplify conditional expression (PVS-Studio)
by Marvin 13 Oct '15

13 Oct '15

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=17328 Your paranoid android. === w1064 (32 bit security) === security.c:3738: Test failed: MACHINE\Software owner SID != Administrators SID. security.c:3778: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:3782: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:3791: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:3778: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:3782: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:3791: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

1 0

Re: [PATCH v2 5/5] d3d8/tests: Uninitialized varyings tests.
by Marvin 13 Oct '15

13 Oct '15

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=17302 Your paranoid android. === w1064 (32 bit visual) === visual.c:8250: Test failed: Got unexpected color 0xffffffff, case 3. visual.c:8250: Test failed: Got unexpected color 0x00800000, case 5. visual.c:8250: Test failed: Got unexpected color 0x00800000, case 6.

2 1

Re: [PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function
by Stefan Dösinger 13 Oct '15

13 Oct '15

> Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato <rikyz619(a)gmail.com>: > > +HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in, > + struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags, > + const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter) I am not convinced that this is how we want blits to work. I was looking into some blit cleanups myself a few months ago, but got stuck in swapchain related sidequests, mostly to get rid of wined3d_swapchain_blit. My thinking re blitting is that we want to separate things into d3d9-style StretchRect (does color conversion, multisample resolve, stretching, color keying, ...) and CopySubresourceRegion (does sysmem<->vidmem transfers). Mapping d3d8+ methods on top of these calls is pretty simple. ddraw is trickier though and I cannot promise yet that it will work. Many things can be solved with staging resources, e.g. to split a color keyed sysmem -> vidmem blit into a copy_sub_resource_region upload and StretchRect color key blit. (StretchRect will need to be a bit more powerful than what d3d9 / d3d10 allow. At least we want sysmem<->sysmem blits supported by it). Henri was arguing for a more powerful blitter in wined3d if I understood him right, that would also be capable of handling the upload of converted surfaces (wined3d_format_texture_info.convert in utils.c). My concern is that this kind of blitter will turn into a god object that's more powerful than what we need (e.g. we don't need signed RGB -> unsigned RGB conversion while transfering from a sysmem vertex buffer to a vidmem volume texture), but I didn't get very far in proving that my alternative approach works.

2 1

Re: [PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function
by Józef Kucia 13 Oct '15

13 Oct '15

Just some nitpicks. On Mon, Oct 12, 2015 at 5:23 PM, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > initial usage in d3d8 > > Signed-off-by: Riccardo Bortolato <rikyz619(a)gmail.com> > --- > dlls/d3d8/device.c | 12 ++++++------ > dlls/wined3d/texture.c | 14 ++++++++++++++ > dlls/wined3d/wined3d.spec | 1 + > include/wine/wined3d.h | 3 +++ > 4 files changed, 24 insertions(+), 6 deletions(-) > > diff --git a/dlls/d3d8/device.c b/dlls/d3d8/device.c > index 2b11923..95684c7 100644 > --- a/dlls/d3d8/device.c > +++ b/dlls/d3d8/device.c > @@ -1093,8 +1093,8 @@ static HRESULT WINAPI d3d8_device_CopyRects(IDirect3DDevice8 *iface, > if (!rect_count && !src_rects && !dst_points) > { > RECT rect = {0, 0, src_w, src_h}; > - wined3d_surface_blt(dst->wined3d_surface, &rect, > - src->wined3d_surface, &rect, 0, NULL, WINED3D_TEXF_POINT); > + wined3d_texture_blt(dst->wined3d_texture, dst->sub_resource_idx, &rect, > + src->wined3d_texture, src->sub_resource_idx, &rect, 0, NULL, WINED3D_TEXF_POINT); > } > else > { > @@ -1109,8 +1109,8 @@ static HRESULT WINAPI d3d8_device_CopyRects(IDirect3DDevice8 *iface, > RECT dst_rect = {dst_points[i].x, dst_points[i].y, > dst_points[i].x + w, dst_points[i].y + h}; > > - wined3d_surface_blt(dst->wined3d_surface, &dst_rect, > - src->wined3d_surface, &src_rects[i], 0, NULL, WINED3D_TEXF_POINT); > + wined3d_texture_blt(dst->wined3d_texture, dst->sub_resource_idx, &dst_rect, > + src->wined3d_texture, src->sub_resource_idx, &src_rects[i], 0, NULL, WINED3D_TEXF_POINT); > } > } > else > @@ -1121,8 +1121,8 @@ static HRESULT WINAPI d3d8_device_CopyRects(IDirect3DDevice8 *iface, > UINT h = src_rects[i].bottom - src_rects[i].top; > RECT dst_rect = {0, 0, w, h}; > > - wined3d_surface_blt(dst->wined3d_surface, &dst_rect, > - src->wined3d_surface, &src_rects[i], 0, NULL, WINED3D_TEXF_POINT); > + wined3d_texture_blt(dst->wined3d_texture, dst->sub_resource_idx, &dst_rect, > + src->wined3d_texture, src->sub_resource_idx, &src_rects[i], 0, NULL, WINED3D_TEXF_POINT); > } > } > } > diff --git a/dlls/wined3d/texture.c b/dlls/wined3d/texture.c > index d5f9591..d93c241 100644 > --- a/dlls/wined3d/texture.c > +++ b/dlls/wined3d/texture.c > @@ -1431,6 +1431,20 @@ static HRESULT volumetexture_init(struct wined3d_texture *texture, const struct > return WINED3D_OK; > } > > +HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in, > + struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags, > + const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter) > +{ > + struct wined3d_resource *dst_resource = wined3d_texture_get_sub_resource(dst_texture, dst_idx); > + struct wined3d_resource *src_resource = wined3d_texture_get_sub_resource(src_texture, src_idx); > + > + if (!dst_resource || !src_resource) > + return WINED3DERR_INVALIDCALL; > + > + return wined3d_surface_blt(surface_from_resource(dst_resource), dst_rect_in, > + surface_from_resource(src_resource), src_rect_in, flags, fx, filter); > +} > + > HRESULT CDECL wined3d_texture_create(struct wined3d_device *device, const struct wined3d_resource_desc *desc, > UINT level_count, DWORD surface_flags, const struct wined3d_sub_resource_data *data, void *parent, > const struct wined3d_parent_ops *parent_ops, struct wined3d_texture **texture) > diff --git a/dlls/wined3d/wined3d.spec b/dlls/wined3d/wined3d.spec > index 1569e24..22c6d23 100644 > --- a/dlls/wined3d/wined3d.spec > +++ b/dlls/wined3d/wined3d.spec > @@ -259,6 +259,7 @@ > @ cdecl wined3d_swapchain_set_window(ptr ptr) > > @ cdecl wined3d_texture_add_dirty_region(ptr long ptr) > +@ cdecl wined3d_texture_blt(ptr long ptr ptr long ptr long ptr long) > @ cdecl wined3d_texture_create(ptr ptr long long ptr ptr ptr ptr) > @ cdecl wined3d_texture_decref(ptr) > @ cdecl wined3d_texture_generate_mipmaps(ptr) > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index 1735b95..b5f705c 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -2531,6 +2531,9 @@ void __cdecl wined3d_swapchain_set_window(struct wined3d_swapchain *swapchain, H > > HRESULT __cdecl wined3d_texture_add_dirty_region(struct wined3d_texture *texture, > UINT layer, const struct wined3d_box *dirty_region); > +HRESULT __cdecl wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in, > + struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags, > + const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter); I think it would be preferred to use dst_sub_resource_idx and src_sub_resource_idx. Mostly for consistency. Also, the patch 6 and 7 should be probably merged. It doesn't make sense to leave unused fields just to remove them in the next patch.

2 1

Re: kernel32: add a stub for CancelSynchronousIo
by Dmitry Timoshkov 13 Oct '15

13 Oct '15

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI CancelSynchronousIo(HANDLE thread) > +{ > + FIXME("(%p): stub\n", thread); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return FALSE; > +} ... > +@ stdcall CancelSynchronousIo(ptr) Please have a look at other .spec file entries how a thread handle (or HANDLE in general) is supposed to be represented. -- Dmitry.

3 2

Re: [PATCH 2/2] dxgi/tests: Add test for IDXGIAdapter::CheckInterfaceSupport().
by Marvin 13 Oct '15

13 Oct '15

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=17326 Your paranoid android. === w1064 (32 bit device) === device.c:1188: Test failed: Got unexpected hr 0, test 16. device.c:1188: Test failed: Got unexpected hr 0x87a0001, test 39. === w1064 (64 bit device) === device.c:1188: Test failed: Got unexpected hr 0, test 16. device.c:1242: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1242: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1242: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1242: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1188: Test failed: Got unexpected hr 0, test 39. device.c:1242: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1242: Test failed: Got usage 160, expected 60, test 42, buffer 15.

1 0

Re: mshtml: Add IHTMLEditServices stub implementation. Take 4.
by Marvin 13 Oct '15

13 Oct '15

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=17322 Your paranoid android. === w1064 (32 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 === w1064 (64 bit htmldoc) === htmldoc.c:3003: Test failed: unexpected command 183 htmldoc.c:3555: Test failed: unexpected call IsErrorUrl htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:2876: Test failed: unexpected state L"uninitialized", expected 4 htmldoc.c:2876: Test failed: VT_I4(out)=0, expected 4 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:875: Test failed: unexpected call htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 101 htmldoc.c:3003: Test failed: unexpected command 132

1 0