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

Re: [PATCH 1/3] ws2_32: Implement a basic synchronous TransmitFile (try 2).
by Marvin 08 Oct '15

08 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=17148 Your paranoid android. === w7pro64 (32 bit sock) === sock.c:7346: Test failed: bytesReturned isn't supposed to be 1 sock.c:7370: Test failed: GetOverlappedResult failed, error 0 === w2008s64 (64 bit sock) === sock: unhandled exception c0000005 at 000007FEFF312045

1 0

Re: [PATCH 3/6] d3d9/tests: Add helpers to avoid multiple readbacks of the render target surface.
by Henri Verbeet 08 Oct '15

08 Oct '15

On 8 October 2015 at 01:26, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > My feeling is that we could improve the readback performance further in > wined3d, regardless of this patch. Possibly, but note that GetRenderTargetData() isn't terribly fast on Windows either. I like the concept, but the implementation probably needs some work. I'd like to have an interface that can work for d3d10/11 as well, so the device parameter probably needs to go. (See also how get_texture_color() is used in d3d10core.) Maybe return a structure that wraps both the readback surface and locked rect to avoid declaring those as separate parameters. E.g.: struct surface_readback rb; get_surface_readback(backbuffer, &rb) color = get_readback_color(&rb, x, y); release_surface_readback(&rb); (Not sure on the naming.) I also think getPixelColor() should then be implemented on top of this. I think masking out the alpha/X channel was the wrong decision, and we should fix that at some point, but for the time being you can of course still mask the result of get_readback_color().

1 0

Re: [PATCH 6/6] d3d8/tests: Uninitialized varyings tests.
by Marvin 08 Oct '15

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

1 0

Re: [PATCH 4/6] d3d9/tests: Uninitialized varyings tests.
by Marvin 08 Oct '15

08 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=17141 Your paranoid android. === w8 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 4. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 7. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 10. visual.c:20260: Test failed: Got unexpected color 0xff000000, case 11. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 12. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 13. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 16. === w864 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 4. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 7. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 10. visual.c:20260: Test failed: Got unexpected color 0xff000000, case 11. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 12. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 13. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 16. === w1064 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 4. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 7. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 10. visual.c:20260: Test failed: Got unexpected color 0xff000000, case 11. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 12. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 13. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 16. === w864 (64 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 4. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 7. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 10. visual.c:20260: Test failed: Got unexpected color 0xff000000, case 11. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 12. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 13. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 16. === w1064 (64 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 4. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 7. visual.c:20260: Test failed: Got unexpected color 0xffffffff, case 10. visual.c:20260: Test failed: Got unexpected color 0xff000000, case 11. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 12. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 13. visual.c:20260: Test failed: Got unexpected color 0x00800000, case 16.

1 0

Re: [PATCH 3/6] d3d9/tests: Add helpers to avoid multiple readbacks of the render target surface.
by Marvin 08 Oct '15

08 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=17140 Your paranoid android. === w8 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w864 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w1064 (32 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w864 (64 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w1064 (64 bit visual) === visual.c:7274: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000.

1 0

Re: mshtml: Treat "data:" as Gecko special URI scheme
by Alex Henrie 08 Oct '15

08 Oct '15

I tried your patch and it worked for loading embedded resources within a page, but I still could not type data:text/plain,Hello%20world! into the address bar and get anything back. Do you have plans to make the address bar work too? -Alex

4 5

Re: [PATCH 2/6] d3d9/tests: Test uninitialized texture varyings with transformed vertices.
by Marvin 08 Oct '15

08 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=17139 Your paranoid android. === w8 (32 bit visual) === visual.c:7209: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w864 (32 bit visual) === visual.c:7209: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w1064 (32 bit visual) === visual.c:7209: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w864 (64 bit visual) === visual.c:7209: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000. === w1064 (64 bit visual) === visual.c:7209: Test failed: Test texcoord1 alpha returned color 0x00ffffff, expected 0x00000000.

1 0

Re: [PATCH 1/2] oledb32: Support VARIANT(VT_NULL)->DBTYPE_WSTR in GetConversionSize
by Michael Stefaniuc 08 Oct '15

08 Oct '15

Alistair, On 10/08/2015 11:06 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/oledb32/convert.c | 2 ++ > dlls/oledb32/tests/convert.c | 6 ++++++ > 2 files changed, 8 insertions(+) > > diff --git a/dlls/oledb32/convert.c b/dlls/oledb32/convert.c > index a92369f..21938aa 100644 > --- a/dlls/oledb32/convert.c > +++ b/dlls/oledb32/convert.c > @@ -1416,6 +1416,8 @@ static HRESULT WINAPI convert_GetConversionSize(IDataConvert* iface, > case DBTYPE_VARIANT: > if(V_VT((VARIANT*)src) == VT_BSTR) > *dst_len = (SysStringLen(V_BSTR((VARIANT*)src))+1) * sizeof(WCHAR); > + else if(V_VT((VARIANT*)src) == VT_NULL) > + *dst_len = 110; what is the magic number 110? I looked at the surrounding code but I don't see any other magic numbers assigned to dst_len. bye michael

2 1

Re: [v3 09/10] wined3d: don't pass a wined3d_volume to device_volume_created callback anymore
by Henri Verbeet 07 Oct '15

07 Oct '15

On 6 October 2015 at 10:36, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index a354308..f1ead48 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -2034,7 +2034,7 @@ struct wined3d_device_parent_ops > struct wined3d_surface *surface, void **parent, const struct wined3d_parent_ops **parent_ops); > HRESULT (__cdecl *volume_created)(struct wined3d_device_parent *device_parent, > struct wined3d_texture *wined3d_texture, unsigned int sub_resource_idx, > - struct wined3d_volume *volume, void **parent, const struct wined3d_parent_ops **parent_ops); > + void **parent, const struct wined3d_parent_ops **parent_ops); I think you should be able to remove the forward declaration of struct wined3d_volume as well now.

2 1

Re: [v3 06/10] d3d9: make use of wined3d_texture_map in d3d9_volume_LockBox
by Henri Verbeet 07 Oct '15

07 Oct '15

On 6 October 2015 at 10:36, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index eb4a0fc..e5111ab 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2335,6 +2335,8 @@ void wined3d_volume_get_pitch(const struct wined3d_volume *volume, UINT *row_pit > void wined3d_volume_load(struct wined3d_volume *volume, struct wined3d_context *context, > BOOL srgb_mode) DECLSPEC_HIDDEN; > void wined3d_volume_invalidate_location(struct wined3d_volume *volume, DWORD location) DECLSPEC_HIDDEN; > +HRESULT wined3d_volume_map(struct wined3d_volume *volume, > + struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); This needs DECLSPEC_HIDDEN. Applies to patch 7/10 as well.

1 0