December 2010 - Wine-devel - list.winehq.org

poor Wine performance creating fat dialogs
by Andreas Pflug 02 Dec '10

02 Dec '10

I'm investigating running a commercial ERP system under Wine (only binary available). It mostly works, but creating the main dialogs for item, customer and such will need around 25 seconds, while running on Wxx it takes 2-3 seconds. After that, there's no serious performance impact working on these dialogs. The dialogs contain a lot of controls, like 500 or so each, so I suspect that's what makes things slow. I'm willing to investigate this in the wine sources, if it makes sense. So before I start I'd like to know if there are known or suspected inefficient code regions that might cause the problem? Maybe some win<->x11 translation tables that degrade with 1000+ windows? Or has this been observed before, and the problem is outside of wine's scope? Any hint appreciated. Regards, Andreas

3 3

Re: [PATCH] shell32/tests: Fixed SHPathPrepareForWriteW tests on Asian platforms.
by Marvin 02 Dec '10

02 Dec '10

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=7381 Your paranoid android. === WNT4WSSP6 (32 bit shlfileop) === shlfileop.c:2207: Test failed: SHGetNewLinkInfoA succeeded

1 0

Death to win9x?
by Dan Kegel 01 Dec '10

01 Dec '10

I'm all for removing stuff that nobody needs anymore. I imagine there are still a few popular older apps that will force us to keep some old win9x behaviors around, though, so we probably won't be able to remove the 'emulate win98' choice from winecfg any time soon.

3 3

Re: [PATCH 4/5] quartz: Add quality control to sound renderer
by Alexandre Julliard 01 Dec '10

01 Dec '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > --- > dlls/quartz/dsoundrender.c | 29 +++++++++++++++++++++++++++++ > 1 files changed, 29 insertions(+), 0 deletions(-) It breaks here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so dsoundrender.c && touch dsoundrender.ok dsoundrender.c:153: Test succeeded inside todo block: IUnknown_QueryInterface returned 0 dsoundrender.c:153: Test succeeded inside todo block: Pointer is NULL dsoundrender.c:154: Test succeeded inside todo block: IUnknown_Release should return 1, got 1 make: *** [dsoundrender.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Stopping Win9x testing
by Greg Geldorp 01 Dec '10

01 Dec '10

> From: Wolfram Sang > > > I'll mark the Win9x VMs offline when there's nothing queued to run on them. > > Then in a weeks time I can delete them after all jobs referring to them > > have been retired/deleted (referential integrity in the database). > > That means they even won't be available then for some specific corner-case > tests (in which they are selected manually)? Hmm, is there much overhead > involved to keep them "just in case"? Yeah, that might be a good idea. Currently VMs are divided into a "Base" and a "Extra" group, I can add a "Retired" group to hold the Win9x VMs. VMs in this group wouldn't participate in the daily winetest run, wouldn't be used for verification of wine-patches submissions and wouldn't be selected by default when manually submitting a job. However, they would be available for selection if you click "Show all VMs" button when submitting a job. This will require some changes to the code, but nothing major. I'll look into it. Greg.

1 0

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
by Alexandre Julliard 01 Dec '10

01 Dec '10

Peter Urbanec <winehq.org(a)urbanec.net> writes: > +static BOOL load_funcs(void *handle) > +{ > +#define LOAD_FUNCPTR(f) if((p##f = (void*)wine_dlsym(handle, #f, NULL, 0)) == NULL) \ > + { ERR("Can not find " #f "\n"); return FALSE; } else { TRACE("Loaded function " #f "\n"); }; > + > + /* Platform API */ > + LOAD_FUNCPTR(clGetPlatformIDs) > + LOAD_FUNCPTR(clGetPlatformInfo) > + > + /* Device APIs */ > + LOAD_FUNCPTR(clGetDeviceIDs) > + LOAD_FUNCPTR(clGetDeviceInfo) Why are you loading everything dynamically instead of simply linking to it? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
by Roderick Colenbrander 01 Dec '10

01 Dec '10

It looks fine to me, but I'm worried whether it can work properly in the end. A few months ago I worked on Cuda support for something (I implemented nvcuda.dll which is what cuda runtime libraries like cudart or physx are using). Certain lowlevel nvcuda applications worked, but more fancy applications didn't. I had some contact with Nvidia about it and it was not possible to support Cuda without assistance on their side. OpenCL is a little different of course, but I fear that not all OpenCL implementations will like wrapping. What OpenCL applications have you tried so far? The Nvidia GPU Computing SDK (or whatever it was called) has a ton of samples for both Cuda and OpenCL. Do all their OpenCL samples work? Roderick On Mon, Nov 29, 2010 at 2:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > Resending because previous patch was mangled by Thunderbird. > > --- > dlls/opencl/opencl.c | 1142 > +++++++++++++++++++++++++++++++++++++++++++++++ > dlls/opencl/opencl.spec | 159 ++++--- > 2 files changed, 1232 insertions(+), 69 deletions(-) > > > > > >

2 1

Re: include: Fix error logic
by Alexandre Julliard 01 Dec '10

01 Dec '10

André Hentschel <nerv(a)dawncrow.de> writes: > The file is nearly always used with one of both, so "or" makes no sense. > Also if you have a look through tchar.h you see it catches all cases, > but not the case where both are defined It doesn't make any sense to define both. -- Alexandre Julliard julliard(a)winehq.org

1 0

Stopping Win9x testing
by Greg Geldorp 01 Dec '10

01 Dec '10

> From: Paul Vriens > > On 11/30/2010 04:41 PM, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly questionable. > > We don't try to emulate the Win9x behavior anyway, except in a very few > > cases (which most likely don't have tests...) so it only serves to > > document historical behavior that nobody cares about any longer. > > > > I wouldn't be opposed to switching off win9x test runs and getting rid > > of the corresponding broken(). > > So the first thing is a patch to winetest.exe and the winetest website > and at the same time tell Greg to exclude it from 'patchwatcher' and the > batch running of the (almost) daily winetests. I'll mark the Win9x VMs offline when there's nothing queued to run on them. Then in a weeks time I can delete them after all jobs referring to them have been retired/deleted (referential integrity in the database). So for the next week you'll see a red dot with "One or more VMs are offline" on the testbot main page, don't be alarmed by this. Greg.

2 1