wine-devel September 2012

wine-devel@winehq.org

54 participants
188 discussions

Re: [PATCH 1/6] mshtml: Moved getting frame by name to separated function
by Alexandre Julliard 03 Sep '12

03 Sep '12

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlwindow.c | 127 > ++++++++++++++++++++++++++-------------------- > 1 files changed, 72 insertions(+), 55 deletions(-) gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -Werror -I/usr/include/freetype2 -g -O2 -o htmlwindow.o htmlwindow.c htmlwindow.c: In function ‘HTMLWindow2_item’: htmlwindow.c:416:13: error: variable ‘hres’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make: *** [htmlwindow.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/3] kernel32: Support UTF-7 in MultiByteToWideChar.
by Alexandre Julliard 03 Sep '12

03 Sep '12

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I was asked to split this patch up, so I did. The complaint about the > last version was "You are still overflowing the source." I have not > been able to find any test case that my implementation handled > incorrectly, however, I did find that (*src == 0 && srclen < 0) will > never evaluate to true, so I removed this if statement from the code. I > also changed example #2 in the tests to be slightly more stringent, but > the last patch would also have passed. > > If this patch series is rejected, please show me a test case that > demonstrates what I am doing wrong. You don't have a single test with an explicit source length, so obviously you are not going to find problems in that area. Like I said, you need a lot more tests. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] msctf: also free the sink in the non-source branch (Coverity)
by Marvin 03 Sep '12

03 Sep '12

1 0

Re: wined3d: Use backup swapchain DC for devices created with desktop window.
by Henri Verbeet 03 Sep '12

03 Sep '12

On 3 September 2012 00:51, Adam Jakubek <ajakubek(a)gmail.com> wrote: > Hi, > > This patch causes wined3d to use backup swapchain DC when > IDirect3DDevice9 is created using the desktop window. > Windows allows to create such device as long its type is > D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF. > > Unpatched Wine will fail in IDirect3D9_CreateDevice method, since it > incorrectly uses the X root window. > > Relevant d3d test case is included. > Patch closes bug #18490. > How is actual rendering to the desktop window supposed to work?

2 1

Re: [PATCH 6/6] mshtml: Added IHTMLIFrameElement3 stub implementation
by Marvin 03 Sep '12

03 Sep '12

1 0

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 03 Sep '12

03 Sep '12

I had another look and like to give some suggestion. On 02.09.2012 22:28, Nozomi Kodama wrote: + sinb = sqrt( 1.0f - matrix->u.m[2][2] * matrix->u.m[2][2] ); I'd prefer to declare the variables as locally as possible. + D3DXSHRotateZ(temp5, order, alpha, temp4); + memcpy(out, temp5, sizeof(float) * order * order); + + return out; You probably may avoid the memcpy. What do you think about something like: return D3DXSHRotateZ(out, order, alpha, temp4); + FLOAT alpha, beta, gamma, sinb, temp1[36], temp2[36], temp3[36], temp4[36], temp5[36]; Do we really need that much temps? I think one is enough, but definitively 2 (I think you are able to use out as one "temp"). If you don't like the usage of out, you may use temp2 instead, but I think it could be avoided. D3DXSHRotateZ(out, order, gamma, in); RotateX(temp, order, 1, out); D3DXSHRotateZ(out, order, beta, temp); RotateX(temp, order, 0, out); D3DXSHRotateZ(out, order, alpha, temp); +static FLOAT* RotateX(FLOAT *out, UINT order, UINT pm, FLOAT *in) The return value is never used. Probably you may return void or you'd like to stack the function calls above a bit and reuse the returned pointer. You also may use "BOOL pm" since it uses only 0 and 1 or you may pass the "FLOAT a" directly to the function. Whatever pm stands for... Cheers Rico

2 1

Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)
by Dmitry Timoshkov 03 Sep '12

03 Sep '12

Marcus Meissner <meissner(a)suse.de> wrote: > + if (!pInitializeConditionVariable) { > + skip("no condition variable support.\n"); > + return; > + } Probably this should be a win_slip(). > + /* fprintf(stderr,"produced %d, c1 %d, c2 %d\n", totalproduced, cnt1, cnt2); */ > + > + /* The sleeps of the producer or consumer should not go above 10000, otherwise > + * the implementation does not sleep correctly. */ > + > + /* fprintf(stderr,"producer sleep %d, consumer sleep %d\n", condvar_producer_sleepcnt, condvar_consumer_sleepcnt); */ There is trace() for debug output, it's shorter and more convenient IMHO. -- Dmitry.

4 3

Re: d3dx9_36: Implement D3DXSHRotate
by Rico Schüller 03 Sep '12

03 Sep '12

On 02.09.2012 23:46, Nozomi Kodama wrote: > For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So > we must check whether it is acceptable for other D3DXSH functions to > give such an order. If it is not acceptable, then we must know what the > function returns. Yes, they do and I agree with you. But why do you chose to try from 0 to 9 (<10) instead of 0-7 (<8) - which I think is enough and nothing more changes? (It includes the first round of not touched values.) Asking the other way around, why don't you try lets say till 1000? I guess the easy answer is, because the output values won't be touched for orders >6. The test results show the same for the tests 7-9 (and would til 1000) and thus testing for 7 is enough, testing 8 and 9 brings no new information, beside you would miss to test from 10 to open end. > > For the out of bound problem, I agree that we reach an out of bound. But > it is not a problem, since for such an index, expected is defined by an > other value. > If there is a complaining compiler about this, I can modify the tests > though. I'm not sure if the compiler is complaining, but I think it's much better to set it in the else case. You may get an unhandled exception and this is not what the software should do in the first place, it should run and not produce exceptions! :-) The same is done in test_D3DXSHRotateZ, which I'm not happy about it. Cheers Rico

1 0

Re: wined3d: Use backup swapchain DC for devices created with desktop window.
by Marvin 02 Sep '12

02 Sep '12

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 http://testbot.winehq.org/JobDetails.pl?Key=21350 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PRO (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a.

1 0

Re : d3dx9_36: Implement D3DXSHRotate
by Nozomi Kodama 02 Sep '12

02 Sep '12

For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So we must check whether it is acceptable for other D3DXSH functions to give such an order. If it is not acceptable, then we must know what the function returns. For the out of bound problem, I agree that we reach an out of bound. But it is not a problem, since for such an index, expected is defined by an other value. If there is a complaining compiler about this, I can modify the tests though. Nozomi

1 0

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 September 2012