wine-devel April 2015

wine-devel@winehq.org

54 participants
164 discussions

Re: [1/1] dwrite: case insensitive font search
by Nikolay Sivov 11 Apr '15

11 Apr '15

On 04/10/2015 10:20 PM, Julius Schwartzenberg wrote: > Running the tests on MS Windows, it turns out that Nikolay Sivov was > correct that it should just be a case insensitive search: > https://www.winehq.org/pipermail/wine-devel/2015-April/107309.html > This allows Samsung Smart View 2.0 to get further with starting up. Hi, Julius. This looks good enough, except subject line needs to be improved a bit to follow a pattern we usually use, something like 'dwrite: Font family lookup should be case-insensitive', but that's not critical at all. Thanks for tracking this down.

1 0

Re: [PATCH 8/9] wined3d: Handle color key dirtification in wined3d_cs_exec_set_texture.
by Henri Verbeet 10 Apr '15

10 Apr '15

On 9 April 2015 at 22:48, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index eb5c3b0..a888552 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -1068,7 +1068,10 @@ DWORD get_flexible_vertex_size(DWORD d3dvtVertexType) DECLSPEC_HIDDEN; > #define STATE_POINT_SIZE_ENABLE (STATE_FRAMEBUFFER + 1) > #define STATE_IS_POINT_SIZE_ENABLE(a) ((a) == STATE_POINT_SIZE_ENABLE) > > -#define STATE_HIGHEST (STATE_POINT_SIZE_ENABLE) > +#define STATE_COLOR_KEY (STATE_POINT_SIZE_ENABLE + 1) You should handle this in debug_d3dstate() and validate_state_table() as well.

1 0

[RFC] mshtml: Remove nsIDOMWindowUtils::SetCriticalDisplayPortForElement.
by Thomas Faber 10 Apr '15

10 Apr '15

Hey Jacek, I just got an MSVC /RTCs stack pointer mismatch error after this call in mshtml's CustomDoc_Release: nsIDOMWindowUtils_CycleCollect(window_utils, NULL, 0); After some investigation I found that the vtable for this class was off by one element. The culprit seems to be SetCriticalDisplayPortForElement. The function got removed here in Gecko: http://sourceforge.net/p/wine/wine-gecko/ci/ed28b621505812d584723bfb389983b… However the latest nsiface.idl in Wine still has it: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/mshtml/nsiface.idl#l… I did my testing on mshtml 1.7.37 with Wine Gecko 2.34 but it looks like this is still present in the latest code as well. Do you agree with my analysis (i.e. the attached patch) here, or do you think I'm missing something? Thanks! And thanks for maintaining Wine Gecko... this truly opened my eyes to the complexity of that task ;) -Thomas

2 1

Re: [PATCH 2/2] wined3d: Implement color keying in the glsl fragment pipeline (v2).
by Marvin 10 Apr '15

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

1 0

Re: [PATCH 3/9] wined3d: Implement color keying in arbfp_blit.
by Matteo Bruni 10 Apr '15

10 Apr '15

2015-04-09 22:48 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>: > This intentionally discards on the alpha value. To do a proper color > compare we have to migrate fixed function pipeline color keying and > blits at the same time because the color keying conversion changes the > texture contents and can cause the key not to match. > --- > dlls/wined3d/arb_program_shader.c | 68 +++++++++++++++++++++++++++++++++------ > dlls/wined3d/surface.c | 51 +++++++++++++++++++---------- > dlls/wined3d/swapchain.c | 2 +- > dlls/wined3d/wined3d_private.h | 7 ++-- > 4 files changed, 99 insertions(+), 29 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c b/dlls/wined3d/arb_program_shader.c > index 79439f5..f740123 100644 > --- a/dlls/wined3d/arb_program_shader.c > +++ b/dlls/wined3d/arb_program_shader.c > @@ -7539,7 +7549,24 @@ static GLuint arbfp_gen_plain_shader(struct arbfp_blit_priv *priv, > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader)); > > shader_addline(&buffer, "!!ARBfp1.0\n"); > - shader_addline(&buffer, "TEX result.color, fragment.texcoord[0], texture[0], %s;\n", tex_target); > + > + if (type->use_color_key) > + { > + shader_addline(&buffer, "TEMP color;\n"); > + shader_addline(&buffer, "TEMP compare;\n"); > + shader_addline(&buffer, "PARAM color_key = program.local[%u];\n", ARBFP_BLIT_PARAM_COLOR_KEY); > + shader_addline(&buffer, "TEX color, fragment.texcoord[0], texture[0], %s;\n", tex_target); > + shader_addline(&buffer, "SGE compare.r, color.a, color_key.a;\n"); > + shader_addline(&buffer, "SGE compare.g, -color.a, color_key.a;\n"); > + shader_addline(&buffer, "MUL compare, compare.r, -compare.g;\n"); > + shader_addline(&buffer, "KIL compare;\n"); > + shader_addline(&buffer, "MOV result.color, color;\n"); If you're checking for an exact match, that doesn't look right. You probably want something like: ... SGE compare.r, color.a, color_key.a; SGE compare.g, -color.a, -color_key.a; MUL compare, compare.r, compare.g; ... I might have misunderstood the point of the shader though, if that's the case then ignore this.

2 1

Re: [PATCH 3/4] d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame{1-3}
by Stefan Dösinger 09 Apr '15

09 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-09 um 16:11 schrieb Aaryaman Vasishta: > +static void test_frame1_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame, &IID_IDirect3DRMFrame, tests, sizeof(tests) / sizeof(*tests)); > ... > +static void test_frame2_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame2, &IID_IDirect3DRMFrame2, tests, sizeof(tests) / sizeof(*tests)); > ... > +static void test_frame3_qi(void) > +{ > ... > + test_qi("frame_qi", (IUnknown *)frame3, &IID_IDirect3DRMFrame3, tests, sizeof(tests) / sizeof(*tests)); With this it won't be possible to find out which test failed if something fails. Please use more informative names for the test_name parameter of test_qi, e.g. "frame1_qi", "frame2_qi" and "frame3_qi". It is a bit unfortunate that you have to duplicate the big structure 3 times. You could in theory share it between the different functions, but then you'd have to lie about which interface you pass to test_qi, and I am not sure if this is nicer. If you can't find a better solution keep it the way it currently is. @Alexandre: The reason why I want to test all interface versions is our experience with ddraw. It has plenty of interface-specific behaviors, some of them depend on which version is called, and some of them depend on which version was used to create the object. (see struct ddraw_surface::version, struct ddraw::version and struct d3d_device::version, as well as various thunks). For this particular test the relevant information is that all interfaces can be queried from all object versions and that there are no refcounting differences, which could be introduced by the presumably aggregated IDirect3DRMObject2 interface. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVJvBaAAoJEN0/YqbEcdMwXYEP/2k4k4qdiGA2sxdv0S6mTaZW RXEPGDY1BqtDyOlw9EzwK+EmQTnE6B4zC25AM55yFAQjaIs8UyAk/TN3b0K+H9xz ZJJIgqGe2x+yIrzKqT70lGqUltYMaENHEw3oh8GdkYnIIK97bG7Y7vK7VZKIDPlh vfxcwG990di77KyPTt3eI4w6BQp4SyyEUxNC5vCy213ML+sF9XjGV+WPkV0UStcX nNCLRcszExminklJgEj4h1S6qcxNVIwJks8vCrgRx9isJfmbK8g5GrAzod3iTSES K1ccZWxGFbXupiT8Je6K5Te6b2PlHZtBVVHb5ndeYQdZJmwZIrTFbE3LjX3o2Vyt m0DvbPzAzNNJO7jREtWVSDXmg2OIaxsaIlMpH+v7VU2csqLNQZCijJ9/q3hN2qLf rYIS7i2fAmWDUoE6uFDOs+VJKDx88OljZaBTV4VFAHYwfeiqr3KXVdYZ3lciViif gjfno0N20inhG/ydjmJOn+tMipj2p1iffHDMaIlXVFhxitTj2Kk/bYp5b65T5q0C dn99clpZKU8xKg8w1I6MQv03CvMla0Z5k5d01H6YCW0YDSHtSnxfXeykxN2PeCGZ wYkTxF/KeSXhg3tLkl7StD1aRJsa5lv98FnJmQA2UWDNlcPfHcvv0Dam8ZsRohEr pPvj1H5GMcaaDGhfCOiZ =Eore -----END PGP SIGNATURE-----

1 0

Re: [PATCH] shell32: Add more knownfolders
by Marvin 09 Apr '15

09 Apr '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=12738 Your paranoid android. === w2000pro (32 bit shellpath) === The test timed out

1 0

Re: TestBot job 11764 results: [1/5] comctl32: Move TaskDialogIndirect function and its test to separate files (try 3)
by Joachim Priesner 09 Apr '15

09 Apr '15

Hi all, this patch series (implementing a basic version of TaskDialog/TaskDialogIndirect) has vanished from the patches list without comment. I'd appreciate any hint on what I did wrong. Thanks Joachim Am Donnerstag, 26. Februar 2015 schrieb Marvin: > VM Status Number of test failures > build completed > w2000pro completed 0 > wxppro completed 0 > w2003std completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w7u completed 0 > w8 completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w2000pro completed 0 > wxppro completed 0 > w2003std completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w7u completed 0 > w8 completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > > === build (build) === > No build failures found > > === w2000pro (32 bit taskdialog) === > No test failures found > > === wxppro (32 bit taskdialog) === > No test failures found > > === w2003std (32 bit taskdialog) === > No test failures found > > === wvistau64 (32 bit taskdialog) === > No test failures found > > === w2008s64 (32 bit taskdialog) === > No test failures found > > === w7u (32 bit taskdialog) === > No test failures found > > === w8 (32 bit taskdialog) === > No test failures found > > === wvistau64 (64 bit taskdialog) === > No test failures found > > === w2008s64 (64 bit taskdialog) === > No test failures found > > === w2000pro (32 bit misc) === > No test failures found > > === wxppro (32 bit misc) === > No test failures found > > === w2003std (32 bit misc) === > No test failures found > > === wvistau64 (32 bit misc) === > No test failures found > > === w2008s64 (32 bit misc) === > No test failures found > > === w7u (32 bit misc) === > No test failures found > > === w8 (32 bit misc) === > No test failures found > > === wvistau64 (64 bit misc) === > No test failures found > > === w2008s64 (64 bit misc) === > No test failures found

2 1

Re: dpnet: Convert Address components to use a list
by Stefan Dösinger 09 Apr '15

09 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-08 um 09:10 schrieb Alistair Leslie-Hughes: > +{ > + if(This->comp_count == This->comp_array_size) > + { > + struct component **temp; > + > + temp = heap_realloc(This->components, sizeof(struct component *) * (This->comp_array_size*2) ); Style hint: You can use sizeof(*temp) here, that way the alloc code doesn't need to be changed when you change the type of temp. This is even more helpful when the declaration of the pointer is in a different file, like in the heap_alloc call that allocates client->components. > + if(This->components) > + { > + This->components[This->comp_count] = item; > + This->comp_count++; > + return TRUE; > + } Can this ever be NULL for a legitimate reason? Note that the heap_realloc call already assumes This->components is not NULL. > @@ -540,8 +596,8 @@ HRESULT DPNET_CreateDirectPlay8Address(IClassFactory *iface, IUnknown *pUnkOuter > > client->IDirectPlay8Address_iface.lpVtbl = &DirectPlay8Address_Vtbl; > client->ref = 1; > - > - list_init(&client->components); > + client->comp_array_size = 4; > + client->components = heap_alloc( sizeof(struct component *) * client->comp_array_size ); Please add error checking here. (The NULL check in add_component doesn't help if this fails. You'll just get a half-working address object where AddComponent always fails) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVJkU+AAoJEN0/YqbEcdMwYRYP/0Vzb0FQDV6xBWc66VFjECxa dSyWsm34yksURXd9H7ayT+cGHQiyfq9dP5MIEL3Lrf7Npiqy7b3DV2NYH1X3foL8 NZoU0R6BSq1XUkqcEWFnXRDIHWs8f0Q1kNyRcUfsuXO4c6vAQOde7CdRtMHuLEy5 DOZjnnSbfAjoKq9Xk3JGJOs1juceoNumojpYE6wtbwDM5Q3Z8DOAdDEvv9qCw9SU Gziuis+LLN2yFDb+cONIKApy/XS/zs2imFS4z/wlKAEu72aGib/64j/d7j48jIxl C7ojDWjWGQj1CDSF6Wn0X80TV5Xjgolgw3ndyPFvqResCk4+UMeoyPaBXLLmozcu VaNtd4sGVTTAe7ivfKVaZx1K0gR8mezsFXEZ2jBfZlTOGHIRiImQ84ORZvahWr7t HYh0ZdDddzNOEbJVAlvxMrB/HLL+ODAOZJaElN6QXyWPBYFIb5AH+VwXeBccahSM xg8xkZLQIPqgDyQaI4TPDCboU5VzptTtl3uKJSy4QX+gV23IFXT9AUnPrWLas+3J qW0pX1tljdTxrVqU3mGvvE3KnUsHyEvx4sBVNWOzEagnSv4TQiabNlkyPfQmJsiH WE/Lx2WTWV9ucLfsGmCNbx+Cu52hDNj1R93hqgpSgAvvUjFeGjxTy4SQFD17ig6M ZFkE66v0L53cG4lQASGw =FqJl -----END PGP SIGNATURE-----

1 0

Re: [1/2] ws2_32/tests: Add tests about retrieving the local address of an interface bound socket
by Marvin 09 Apr '15

09 Apr '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=12730 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2015