wine-devel June 2011

wine-devel@winehq.org

79 participants
247 discussions

Re: wined3d: Use a separate mutex for wndproc_table access.
by Stefan Dösinger 19 Jun '11

19 Jun '11

I can't speak about the conceptual correctness of this patch, although my gut feeling says that you're right. You don't need wined3d_wndproc_mutex_(un)lock. Just use EnterCriticalSection / LeaveCriticalSection directly. wined3d_mutex_lock exists because it is exported from wined3d. On Friday 17 June 2011 21:49:38 Piotr Pawlow wrote: > If CreateDevice is called with hFocusWindow belonging to another thread, > then any code that does SendMessage (or equivalent) to the window while > holding the main wined3d mutex causes a deadlock, because wined3d_wndproc > tries to acquire the same mutex for wndproc_table access. Using a different > mutex for this purpose solves the problem. > --- > dlls/wined3d/wined3d_main.c | 44 > +++++++++++++++++++++++++++++++----------- > 1 files changed, 32 insertions(+), 12 deletions(-)

2 1

Re: CopyFileExW Support
by Jerome Leclanche 19 Jun '11

19 Jun '11

You are severely mixing tabs and spaces, you should fix your editor. You also have a lot of unrelated trailing whitespace changes; granted they all remove trailing whitespace, but since this isn't a small patch, it makes it harder to read. J. Leclanche On Sun, Jun 19, 2011 at 2:40 AM, Arthur Dene Ice <addtheice(a)gmail.com> wrote: > > > > >

1 0

Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 3)
by Marvin 19 Jun '11

19 Jun '11

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=11822 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

1 0

Wrong AppDB link
by wylda＠volny.cz 19 Jun '11

19 Jun '11

Hi, by mistake i linked a wrong bug to FAR Manager: http://appdb.winehq.org/objectManager.php?sClass=version&iId=15928 Could someone remove a link from FAR to bug 27406, please? Thanks, W.

2 1

Re: openal32: test whether alGetError() returns AL_NO_ERROR when called out of context, with fix.
by Chris Robinson 19 Jun '11

19 Jun '11

On Saturday, June 18, 2011 8:32:31 PM Dan Kegel wrote: > Matches native behavior. Makes at least one app happier; see bug 27532. Just to toss in my comments, the "native" behavior referred to is the behavior of Creative's DLLs, but Creative's DLLs aren't the only ones available for Windows. OpenAL Soft behaves the same way as a real DLL as it does a Linux DSO (ie, returns an error from alGetError() when no current context is set), and IIRC, there are Windows apps that prefer using it over Creative's sometimes- unstable drivers. There is at least one other OpenAL implementation available for Windows that some apps use, but I don't know how it behaves and it costs money. IMO, it is a bug in both Creative's DLLs and the affected app. Two bugs nullifying each other, essentially. Using OpenAL Soft's DLL in place of Creative's, in real Windows, would yield the same bug experienced in Wine.

1 0

Re: shdocvw: Add ITaskbarList2 Interface
by Alistair Leslie-Hughes 19 Jun '11

19 Jun '11

Hi André, On 19/06/2011 1:52 AM, André Hentschel wrote: > --- > dlls/shdocvw/taskbarlist.c | 74 ++++++++++++++++++++++++++++--------------- > include/shobjidl.idl | 15 +++++++++ > 2 files changed, 63 insertions(+), 26 deletions(-) Can you please provide a test case to show that this interface exists? Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH 2/2] d3dx9/line: Implemented tests for ID3DXLine's Begin and End methods.
by Marvin 18 Jun '11

18 Jun '11

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=11808 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

STATE_VDECL & friends
by Stefan Dösinger 17 Jun '11

17 Jun '11

Hi, This is a brain core dump before going to bed for the other d3d developers. I did some testing concerning the vertexdeclaration, vertex shader, stream sources and pixel shader states. Currently the first 3 are hard linked, and the pixel shader is also tied to the vertex shader. I was interested which states are invalid how often, and where separating the states makes sense. Basically about 40% of all draws only the pixel shader is invalid. In another 30%-50% the pixel shader and stream source are invalid, and in about 10% to 20% of all draws all 4 states are reapplied anyways. There are relatively few cases where the vertex declaration and vertex shader are changed alone. So what does this mean? We'll have to spit away the pixel shader and stream sources states. The good news is that the stream sources are easy to separate - when the streamsources are invalid only reapply them, if the vdecl or vshader are dirty reapply shader+decl+streamsrc. The bad news is that applying the stream sources is the most expensive part. The pixel shader is already somewhat separated. Changing the pixel shader will only reapply the vertex shader, but not stream sources or other vdecl-related states. Separating vertex and pixel shaders will be tricky and not fully possible on some drivers(needs GL_ARB_separate_shader_objects or ARB shaders) and all shaders(Shader Model 3.0 varying passing) In addition to this we'll have to make parsing of the vertex declaration cheaper. I'll think of something... I'll also write some quick and dirty patches to see how much performance we really get out of these changes. Stefan PS: I attached my debug patch and the output for a few games.

1 0

limits on the number of events, windows and threads?
by Joerg-Cyril.Hoehle＠t-systems.com 17 Jun '11

17 Jun '11

Hi, I vaguely remember reading about a quite low limit on the number of event objects that a thread can hold because each one is said to take up one bit in some 32 or 64 bit mask. That was then invoked as a reason to allocate e.g. event or window objects for as short a time span as possible. Is there such a low limit on the number of events (or other types of handles) than one thread can hold in native or in Wine? Thank you for your help, Jörg Höhle

2 1

Re: winealsa: Avoid deadlock in AudioClient_Stop.
by Andrew Eikum 17 Jun '11

17 Jun '11

Hi Jörg, Patch makes sense to me. I'll put together some patches for the other drivers, unless you beat me to it ;) Thanks, Andrew On 06/17/2011 10:13 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > my patch is not the final word about robust design. > > Consider what happens when > DeleteTimerQueueTimer(g_timer_q, This->timer, INVALID_HANDLE_VALUE) > cannot allocate its CompletionEvent. The function will return with an > (ignored) error and not stop the timers. Do you see a check in > wineoss or winecoreaudio? The later Audio_Release will destroy > critical sections and free memory while the timers are still running! > > A tiny allocation failure => big crash > > Deallocators should not fail when resources are scarce. > > A more robust design would see Audio_Start allocate the completion > event that DeleteTimerQ requires and not start if it can't be sure to stop. > Why require a completion event? Because there's > *no* other way of telling whether a callback might still be invoked. > Even sleeping for more than the timer period is no guarantee rather > than mere heuristics that works on a slightly loaded system. > > Back to my patch. It's funny to think that it would mostly work > without error checking: DeleteTimerQ(event) does something with > event NULL or not, Wait(NULL) would immediately return and > DeleteTimerQ always signals the event when successful. > > Regards, > Jörg Höhle > > > >

1 0

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

Jump to page:

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 June 2011