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

Re: [v5 PATCH 1/2] gdiplus: Implement GdipSetPenTransform
by Marvin Feb. 5, 2016

Feb. 5, 2016

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=20194 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] dwrite/tests: Remove failing test line, we have skips for this now
by Marvin Feb. 4, 2016

Feb. 4, 2016

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=20191 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [v4 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 4, 2016

Feb. 4, 2016

Why did you remove the TRACE from this function?

1 0

Re: [PATCH 3/6] wined3d: Add support for separate sRGB formats.
by Henri Verbeet Feb. 4, 2016

Feb. 4, 2016

On 4 February 2016 at 01:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > - factory->wined3d = wined3d_create(0); > + factory->wined3d = wined3d_create(WINED3D_SEPARATE_SRGB_FORMATS); In some ways I like this, although I wonder if it wouldn't make more sense to handle this in terms of a flag to enable support for SRGB_READ/SRGB_WRITE. I.e., when WINED3D_SAMP_SRGB_TEXTURE and WINED3D_RS_SRGBWRITEENABLE are supported, WINED3DFMT_R8G8B8A8_UNORM and WINED3DFMT_R8G8B8A8_UNORM_SRGB would effectively be the same, while when they aren't you'd get the d3d10+ behaviour. > @@ -5993,7 +5994,7 @@ HRESULT wined3d_init(struct wined3d *wined3d, DWORD flags) > return WINED3D_OK; > } > > - if (!wined3d_adapter_init(&wined3d->adapters[0], 0)) > + if (!wined3d_adapter_init(&wined3d->adapters[0], wined3d, 0)) I'm not a huge fan of this, although I could probably live with it. I guess it's mostly to get at wined3d->flags during format initialization, in which case it may be sufficient to just pass the flags to wined3d_adapter_init(). > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index 1904dd1..718aa18 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -58,8 +58,11 @@ static const struct wined3d_format_channels formats[] = > {WINED3DFMT_DXT4, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_DXT5, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC1_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC1_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC2_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC2_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC3_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC3_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_MULTI2_ARGB8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_G8R8_G8B8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_R8G8_B8G8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, One thought I have about this is that we could just store the channel sizes and shifts for the typeless formats, and then have the typed formats copy the information from there, perhaps instead of the format_base_flags[] table we have now. So you'd have something like this: {WINED3DFMT_R8G8B8A8_UNORM, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_UNORM_SRGB, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_SNORM, WINED3DFMT_R8G8B8A8_TYPELESS, SNORM, SNORM, SNORM, SNORM} {WINED3DFMT_R8G8B8A8_UINT, WINED3DFMT_R8G8B8A8_TYPELESS, UINT, UINT, UINT, UINT} {WINED3DFMT_R8G8B8A8_SINT, WINED3DFMT_R8G8B8A8_TYPELESS, SINT, SINT, SINT, SINT} > @@ -2237,7 +2255,7 @@ static void query_internal_format(struct wined3d_adapter *adapter, > format_clear_flag(format, WINED3DFMT_FLAG_SRGB_WRITE); > > if (!gl_info->supported[ARB_DEPTH_TEXTURE] > - && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) > + && !!texture_info && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) The "!!" before texture_info seems unnecessary. > +static inline BOOL should_use_separate_srgb_gl_texture(const struct wined3d_context *context) That's a fairly long function name. Not that I have a better suggestion though. > +{ > + return !context->gl_info->supported[EXT_TEXTURE_SRGB_DECODE] > + && !(context->swapchain->device->wined3d->flags & WINED3D_SEPARATE_SRGB_FORMATS); > +} The number of pointer dereferences in here is scary. :) (Yeah, I know, there are other places that are just as bad.) Maybe it makes sense to store a copy of the flags in struct d3d_info?

2 1

Re: kernel32: Add test MultiByteToWideChar for code page is 936.
by Alexandre Julliard Feb. 4, 2016

Feb. 4, 2016

Changhui LIU <chliu027028(a)gmail.com> writes: > +static void test_cp936_to_widechar(void) > +{ > + int count = 0; > + int count2 = 0; > + WCHAR wide_buf[4]; > + unsigned char buf[] = {0xbf, 0xb4, 0xc7}; > + > + count = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), NULL, 0); > + ok(count > 0, "returned %d (expected > '0')\n", count); > + > + count2 = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), wide_buf, count); > + todo_wine ok(count2 > 0, "returned %d (expected > '0')\n", count2); > + > + todo_wine ok(count == count2, "expected twice call result is same\n"); That test could be more strict, I expect that there's a defined behavior, not just > 0. Comparing with the results from MB_ERR_INVALID_CHARS would also be interesting. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: hhctrl.ocx: Store window position in registry so that it's persistent between runs.
by Jacek Caban Feb. 4, 2016

Feb. 4, 2016

On 02/04/16 13:05, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/hhctrl.ocx/help.c | 71 > +++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 3 deletions(-) Please ignore this patch. It's not the right fix. Jacek

1 0

Re: [PATCH] include: Add IColumnsInfo interface (resend)
by Nikolay Sivov Feb. 4, 2016

Feb. 4, 2016

On 04.02.2016 12:31, Alistair Leslie-Hughes wrote: > +[ > + object, > + uuid(0c733a11-2a1c-11ce-ade5-00aa0044773d), > + pointer_default(unique) > +] > +interface IColumnsInfo : IUnknown > +{ > + [local] > + HRESULT GetColumnInfo([in, out] DBORDINAL *columns,[out, size_is(*columns)] DBCOLUMNINFO **colinfo, > + [out] OLECHAR *stringsbuffer); > + > + [call_as(GetColumnInfo)] > + HRESULT RemoteGetColumnInfo([in, out] DBORDINAL *columns, [out, size_is((ULONG)*columns)] DBCOLUMNINFO **col_info, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **name_offsets, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **columnid_offsets, > + [in, out] DBLENGTH *string_len, [in, out, unique, size_is((ULONG)*string_len)] OLECHAR **stringsbuffer, > + [out] IErrorInfo **error); > + ULONG in SDK comes from DBORDINAL being ULONGLONG vs ULONG depending on bitness, I agree we probably don't have to duplicate that, and can always use cast. In any case size_is attribute is used in a wrong way, and at least one method prototype does not match SDK.

1 0

Re: [PATCH] usp10: Correct math punctuation handling in itemization
by Marvin Feb. 3, 2016

Feb. 3, 2016

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=20174 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1284: Test failed: 0: uJustification incorrect (0) usp10.c:1284: Test failed: 1: uJustification incorrect (0) usp10.c:1284: Test failed: 2: uJustification incorrect (0) usp10.c:1284: Test failed: 3: uJustification incorrect (0) usp10.c:1284: Test failed: 4: uJustification incorrect (0) usp10.c:1284: Test failed: 5: uJustification incorrect (0) usp10.c:1284: Test failed: 6: uJustification incorrect (0) usp10.c:1284: Test failed: 7: uJustification incorrect (0) usp10.c:1284: Test failed: 8: uJustification incorrect (0) usp10.c:1284: Test failed: 9: uJustification incorrect (0) usp10.c:1300: Test failed: 3: uJustification incorrect (0) usp10.c:1300: Test failed: 5: fDiacritic incorrect (1) usp10.c:1300: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1300: Test failed: 15: fDiacritic incorrect (1) usp10.c:1300: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: [v3 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 3, 2016

Feb. 3, 2016

I think we should keep the FIXME on this one until we use the transform in rendering, maybe change it to semi-stub.

1 0

Re: [PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().
by Henri Verbeet Feb. 3, 2016

Feb. 3, 2016

On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (sample_count > 32) > + return E_FAIL; I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT. > + if (sample_count > 16) > + { > + FIXME("sample_count %u not handled yet.\n", sample_count); > + return S_OK; > + } I think that belongs in wined3d_check_device_multisample_type(). > + hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device, > + wined3dformat_from_dxgi_format(format), sample_count, quality_level_count); > + if (hr == WINED3DERR_INVALIDCALL) > + return E_INVALIDARG; > + if (hr == WINED3DERR_NOTAVAILABLE) > + return S_OK; This is fine, but the d3d10+ API probably makes more sense in the long run. I.e., eventually we'd want to handle the difference in d3d8/9 instead. > +HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device, > + enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, > + DWORD *quality_level_count) I don't think we really want to introduce a new entry point for this. I guess the issue is that we can't get at the wined3d object that created the device from inside d3d11, but I think it would be preferable to do something about that instead. It seems likely that CheckFeatureSupport() and CheckFormatSupport() would run into this as well.

2 1