August 2005 - Wine-Devel - list.winehq.org

Re: [wined3d] texture state sepeartion part3

by Oliver Stieber

--- Jesse Allen <the3dfxdude(a)gmail.com> wrote: > On 8/2/05, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > > Hi, > > This patch moves the setting of states from device to basetexture, states that relate to the > > opengl texture object will only be updated when they are out of sync, this reduces the number > of > > texture object state changes during game play in Axis and allies from severalhundred to 0 or > 1. > > > > > Cool! Does this improve framerates too? > Only a little at the moment because everything else is 'slow', but when everything else is speeded up not having this change would slow things down. > > Jesse > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Aug. 2, 2005

Re: test case demonstrating PeekMessage give up timeslices

by Alexandre Julliard

Felix Nawothnig <felix.nawothnig(a)t-online.de> writes: > (The numbers slightly differ between runs for obvious reasons but they > are close enough (with an error margin of +/- 10 we could maybe make > this a real testcase)) > > So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD > specified it yields execution twice (although it shouldn't at all). PeekMessage is going to call the server and wait on the result, there's no way around it. The extra yield is to avoid hammering the server with requests in stupid apps that constantly poll for messages, since a server call is much more expensive than a Windows system call. This could certainly be changed, but it will require evidence that the changes help for common real cases, not just to make some artificial benchmark show better results. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2005

Re: test case demonstrating PeekMessage give up timeslices

by Felix Nawothnig

I wrote: > So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD > specified it yields execution twice (although it shouldn't at all). Err, that should read "and without PM_NOYIELD specified". Felix

Aug. 2, 2005

Re: test case demonstrating PeekMessage give up timeslices

by Felix Nawothnig

Alexandre Julliard wrote: > You can probably fix it by passing PM_NOYIELD in the PeekMessage > calls. But if your app needs a lot of CPU, restructuring the code to > avoid all the needless polling would give much better results, and > probably improve the behavior on Windows too. That's just a workaround. Our PeekMessage is definitly misbehaving - I ran the attached test-program in Wine and WinXP... here are the results: Wine: wine(a)majestix c $ wine foo.exe NtYieldExecution yielded 100 times PeekMessage(...) yielded 200 times PeekMessage(... PM_NOYIELD) yielded 100 times WinXP: C:\>foo.exe NtYieldExecution yielded 100 times PeekMessage(...) yielded 0 times PeekMessage(... PM_NOYIELD) yielded 0 times (The numbers slightly differ between runs for obvious reasons but they are close enough (with an error margin of +/- 10 we could maybe make this a real testcase)) So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD specified it yields execution twice (although it shouldn't at all). The (real) effect of PM_NOYIELD is described at http://www.piclist.com/techref/os/win/api/win32/func/src/f67_6.htm > You can optionally combine the value PM_NOYIELD with either > PM_NOREMOVE or PM_REMOVE. However, PM_NOYIELD has no effect on 32-bit > Windows applications. It is defined in Win32 solely to provide > compatibility with applications written for previous versions of > Windows, where it was used to prevent the current task from halting > and yielding system resources to another task. 32-bit Windows > applications always run simultaneously. Felix

Aug. 2, 2005

Re: [wined3d] texture state sepeartion part3

by Jesse Allen

On 8/2/05, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > Hi, > This patch moves the setting of states from device to basetexture, states that relate to the > opengl texture object will only be updated when they are out of sync, this reduces the number of > texture object state changes during game play in Axis and allies from severalhundred to 0 or 1. > Cool! Does this improve framerates too? Jesse

Aug. 2, 2005

broken installers

by Ivan Leo Puoti

Microsoft is giving out, free of charge and with free posting, visual studio 2005 beta 2. I received my copy today, I got a CD with visual studio 2005 team suite, a DVD with visual studio 2005 team foundation server, and a CD with sql server 2005 developer edition community technology preview. None of this stuff installs, they all pop up a not very helpful messagebox saying some problem has occurred. Just thought I'd let those guys locked into a small dark room fixing all installers know :-) Ivan. p.s. To make you extra happy they all appear to be using ole

Aug. 2, 2005

Re: WLDAP32: tests for ldap_err2string{A,W} and LdapMapErrorToWin32 (#2)

by Hans Leidekker

On Tuesday 2 August 2005 16:30, Alexandre Julliard wrote: > I don't see any point in testing the actual strings. Surely no code is > going to rely on the exact string contents. OK, fair enough. I had written it to get at the strings, but I agree it has limited value in detecting regressions. -Hans

Aug. 2, 2005

Re: Remove Win16 CurrentDirectory hack

by Alexandre Julliard

Richard Cohen <richard(a)daijobu.co.uk> writes: > The Win32 CurrentDirectory is more likely to be correct, and this > fixes some Win16 installers. No it's not correct, the current directory needs to be per-task for Win16 apps. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2005

Re: WLDAP32: tests for ldap_err2string{A,W} and LdapMapErrorToWin32 (#2)

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > This patch restricts the ldap_err2string tests to a specific thread locale. > > -Hans > > Changelog > Tests for ldap_err2string{A,W} and LdapMapErrorToWin32. I don't see any point in testing the actual strings. Surely no code is going to rely on the exact string contents. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2005

Re: getting the path to .wine

by Alexandre Julliard

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > What's the best way/way usually used in wine to get the full path to .wine? wine_get_config_dir. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2005