March 2013 - Wine-Devel - list.winehq.org

WineD3D performance
by Graham Knap March 18, 2013

March 18, 2013

Hi everyone I would like to try to help with improving the performance of StarCraft II on Wine. I'm working with a friend. Over the past couple of weeks, we have tried to read whatever documentation we could find. We have tried a couple of different approaches to profiling, without much success. My friend got WineD3D running on Windows. We built Wine from current source code, tested this on two different configurations, and got similar results. - my Core 2 E8500 + GeForce 9600GT + Windows XP x86 - his i5-2500 + GeForce 660 + Windows 7 x64 It looks like WineD3D is the cause of most of the performance difference. Windows with its own D3D gave us at least twice the frame rate of Windows + WineD3D. There is some difference between the numbers for Windows + WineD3D and Linux + Wine, but it's much smaller, i.e. something like 25%. Can anyone offer some hints on how to find the most significant causes of the performance difference? Any tips for effective profiling or tracing? Thanks. -- graham

2 2

Re: wined3d: add NVidia GeForce 315M
by Stefan Dösinger March 18, 2013

March 18, 2013

Am 17.03.2013 um 17:08 schrieb Daniel Jeliński <djelinski1(a)gmail.com>: > why can't we get these values from X? They are definitely present in > my Xorg.log. Propose a patch. A few notes though: *) The upcoming GLX_MESA_query_renderer extension will provide a good way to query this info. If this extension will be adopted by the binary drivers is an open question. *) The X.org log would be an extremely ugly way to read this info. The log is at an unknown place, might be readable only by root or might not exist at all. There format of the log messages might change. *) There are vendor specific X11, GLX and GL extensions to query some GPU info *) Wined3d should not deal with GLX_MESA_query_renderer or any other X11 specific things. This should be handled by winex11.drv. > {"GT 320M", CARD_NVIDIA_GEFORCE_GT320M}, /* Geforce 300 - midend mobile */ > + {"315M", CARD_NVIDIA_GEFORCE_315M}, /* Geforce 300 - midend mobile */ > {"320M", CARD_NVIDIA_GEFORCE_320M}, /* Geforce 300 - midend mobile */ Afaics this table is sorted in descending order, for consistency you should swap the 315M and 320M

2 1

Re: msxml3: Embed user/password to uri used to create a moniker (try2)
by Nikolay Sivov March 18, 2013

March 18, 2013

On 3/15/2013 21:43, Nikolay Sivov wrote: > try2: fixed builder leak > Please ignore this one, it removes too much, I have a better version.

1 0

Updating WineWiki Theme?
by Kyle Auble March 16, 2013

March 16, 2013

Hi everybody, Although my hiatus was longer than expected, I've been making progress with updating the wiki code over the past few days (spring break is a very good thing). My workflow is a bit non-linear so I want to sort my changes into patches first, but fingers-crossed, I'll be pushing them to my Bitbucket account by the weekend. I did want to ask for input on a few things: 1. Should we just keep Moinmoin's search, replace it with the custom Google search, or offer both? 2. How about the icon? I can get the standard WineHQ one to display fine, but I'm not sure about which approach to take. Essentially, do what's simplest for us, or should I make it play well with other themes too? 3. Finally, the credits are currently just text links. In the future though, if Dimi wanted to, we could have a "sponsored by Lattica" banner like the Codeweavers ones on the other pages. After I get the theme together & test it some more on different browsers, I can look into migrating the data to the newest Moinmoin version. -Kyle

3 4

Vacation
by Alexandre Julliard March 15, 2013

March 15, 2013

Folks, There won't be any commits next week, as I'll be out skiing... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] Make mac driver the default on OS X (try 2)
by Alexandre Julliard March 15, 2013

March 15, 2013

Josh DuBois <duboisj(a)codeweavers.com> writes: > Ken also noted that the error reporting could be simpler if it were in > gdi instead of user32. My impression, after having poked at it a > while with Ken, is that it is in theory possible that an application > which never tried to create a window would print less noise with the > errors being reported as they are here than it would if the errors > were reported directly from gdi, so that this may be superior because > it is quieter. However, I'm not an expert and if the rigamarole is > not worth the extra lines, I'm sure Alexandre will indicate so by not > applying this. It needs to be printed on window creation because of command line apps, but that's not a reason for doing something as ugly and complicated as this... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/6] atl100/tests: Added class name test for AtlAxWinInit.
by Alexandre Julliard March 15, 2013

March 15, 2013

Qian Hong <qhong(a)codeweavers.com> writes: > @@ -562,6 +562,34 @@ static void test_source_iface(void) > ok(maj_ver == 4 && min_ver == 0, "ver = %d.%d\n", maj_ver, min_ver); > } > > +static void test_ax_win(void) > +{ > + BOOL ret; > + WNDCLASSEXW wcex; > + static const WCHAR AtlAxWin100[] = {'A','t','l','A','x','W','i','n','1','0','0',0}; > + static const WCHAR AtlAxWinLic100[] = {'A','t','l','A','x','W','i','n','L','i','c','1','0','0',0}; > + static HMODULE huser32 = 0, hinstance = 0; > + static BOOL (WINAPI *pGetClassInfoExW)(HINSTANCE, LPCWSTR, WNDCLASSEXW *); > + > + huser32 = GetModuleHandleA("user32.dll"); > + pGetClassInfoExW= (void *)GetProcAddress(huser32, "GetClassInfoExW"); It's not useful to load this dynamically if you are not going to check that it was found. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winmm: Fix notification when recording using MSACM.
by Alexandre Julliard March 15, 2013

March 15, 2013

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > To achieve this, we eliminate the tail call and turn it into a loop, > which allows us to preserve the local state in the variable "last". Please do this as a proper loop, not with a goto. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 3)
by Alexandre Julliard March 15, 2013

March 15, 2013

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > The only comments about v2 were Michael Stefaniuc > suggesting a refactoring and me explaining why > in this particular case, that would not be a good idea. > http://www.winehq.org/pipermail/wine-devel/2013-March/099068.html It's still a good idea, even if the function is ultimately used only in one place. > For v3, I've renamed MulDiv64 to UMulDiv64. Unlike QueryPerformanceCounter, > mmdevapi GetPosition operates on unsigned values. That's a bad name. Don't make internal functions look like Win32 APIs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Aric Stewart : usp10: Update diacritical script handling for non OpenType Itemization.
by Phil Krylov March 14, 2013

March 14, 2013

Hello Aric, On Tue, Feb 5, 2013 at 11:25 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: ef4b7c5948e43d4ceeed98ba4ddbf6c222259d36 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=ef4b7c5948e43d4ceeed98ba4… > > Author: Aric Stewart <aric(a)codeweavers.com> > Date: Tue Feb 5 08:57:44 2013 -0600 > > usp10: Update diacritical script handling for non OpenType Itemization. (snip) > + for (j = i-1; j >= 0 && scripts[j] == first_script && pwcInChars[j] != Numeric_space; j--) > + { > + WORD original = scripts[j]; > + if (original == Script_Ideograph || original == Script_Kana || original == Script_Yi || original == Script_CJK_Han || original == Script_Bopomofo) > + { > + asian = TRUE; > + break; > + } > + if (original != Script_MathAlpha && scriptInformation[scripts[j]].props.fComplex) > + break; > + scripts[j] = scripts[i]; > + if (original == Script_Punctuation2) > + break; > + } > + if (scriptInformation[scripts[j]].props.fComplex || asian) > + scripts[i] = scripts[j]; I am not sure about the logic of this, so I can't commit a good patch, but in the last statement you definitely access scripts[-1] when j reaches the value of 0. Which may cause a crash here or (in my case) later. -- Ph.

2 2