March 2011 - Wine-devel - list.winehq.org

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.
by Eric Pouech 28 Mar '11

28 Mar '11

sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do moreover you're doing several unrelated changes in the same patch, please split up A+ 2011/3/28 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > - PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs > anymore, which makes it easier to reason about use of critical sections. > - psStopEvent was never used like an event rather than a boolean. > - No need to muck with WHDR_DONE. > - No need to keep the unused thread handle object around. > - Abort the playloop in case of error, like I did for mciwave. The error > may not be transient. > > - Free waveHdr and hEvent after closing hWave. Either you believe that > WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must > not yet be freed, or you believe checking for STILLPLAYING is a waste of > code because waveOutReset must have done its job. > > I should have added an ERR() message. > > One should think again about what to do in such a case. Why/when would > sleep help? User-friendlier might be not to wait, not to free WaveHdr > and accept to leak resources in such a case. > > Actually, waveOutClose can fail with STILLPLAYING because waveOutReset > can fail. If you look at winealsa, you'll see it uses CreateEvent to > synchronously wait for acknowledge of the message. Now guess what > happens if CreateEvent fails because memory is tight? > What happens in the app when waveOutClose's CreateEvent fails? > It's always tough to reason about the many error paths. > > Regards, > Jörg Höhle > > > > -- -- Eric Pouech

2 1

w9x/ME users, please test (mciGet/SetYieldProc)
by Joerg-Cyril.Hoehle＠t-systems.com 28 Mar '11

28 Mar '11

Hi, Testbot job #10124 contains a test that works perfectly on machines since w2k, but much to my surprise, mciGetYieldProc returns NULL,0 on testbot's win9x machines. If you have a w9x or a WinME machine, I'd appreciate if you could run the test too. Download & invoke winmm_test.exe midi http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=2 test & patch code: http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=1 If you happen to know why mciGet/SetYieldProc yield NULL/FALSE, please let me hear. NULL looks like an error status than a valid "old value is truly NULL" result. mciSetYieldProc returns FALSE as an error indicator, whereas I'd expect mciSetYieldProc(id,NULL,<any>) to be a valid call. Testbot's w9x machines return: mci.c:639: Test failed: original yieldproc 00000000 mci.c:640: Test failed: Break key is vkey 0 mci.c:643: Test failed: mciSetYieldProc NULL mci.c:648: Test failed: Break key changed to vkey 0 mci.c:664: Test failed: Break key changed to vkey 0 mci.c:674: Test failed: mciSetYieldProc restore Thank you, Jörg Höhle

1 0

Wine compatibility
by Adam Kłobukowski 28 Mar '11

28 Mar '11

Hello I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time. Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine. Is there a solution for this? What is Wine devs position on this matter? Side question: Windows could make a 'clean start' with 64 bit environment, did they? Thank you for your time. Adam Klobukowski

5 6

Re: d3dx9_36: Implement D3DXCreateBox
by Joris Huizer 28 Mar '11

28 Mar '11

Hello, In this patch, one part seemed strange to me: You are declaring vertices as static memory: + static FLOAT vertices[144] But you are changing the values during the function: + + for(i = 0; i< 24; i++) + { + vertices[6 * i ] *= width; + vertices[6 * i + 1] *= height; + vertices[6 * i + 2] *= depth; + } + Given that original values are never restored, I think you can not mark the array as static, otherwise incorrect values are used after the first call. The other arrays are not adapted, so they are fine as static memory (And you may in fact mark those static const) HTH, Joris

4 5

RFC: Remove unimplemented application menus?
by Francois Gouget 27 Mar '11

27 Mar '11

Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

RFC: wined3d: Check for and use FBO blits early in BltOverride
by Chris Robinson 27 Mar '11

27 Mar '11

IDirect3DDevice9::StretchRect is used to stretch-blit between video memory surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However, BltOverride will not accelerate the blit if neither surface is a swapchain or active render target 0, and will fall back to a sysmem->sysmem blit with possible conversions. This seems to happen in between every post-processing (screen-space shader) pass with Oblivion Graphics Extender and Morrowind Graphics Extender, which causes a severe loss in performance. After some testing and talking with Henri, it seems a number of checks aren't needed if FBO blits are available, particularly the swapchain/active render target checks. The attached patch makes BltOverride check for FBO blits earlier, which helps it catch more cases where blits can be accelerated. It provides a significant improvement with the aforementioned programs. I'm not sure of the full consequences of this move, however, particularly with earlier DX versions. Hence a request for comments.

3 3

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Henri Verbeet 27 Mar '11

27 Mar '11

On 21 March 2011 21:56, Adam Martinson <amartinson(a)codeweavers.com> wrote: > > Cuts CPU time in context_apply_fbo_state() in half. This is meaningless. Which applications, and how much time of the total is spent in context_apply_fbo_state()? How does this translate into concrete thing like frame time? More importantly, why does this change come before the one for tracking FBO dirty state? Avoiding redundant FBO entry comparisons completely is likely to have a much more significant effect than making the comparisons themselves slightly cheaper in very specific applications.

2 4

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
by Stefan Dösinger 27 Mar '11

27 Mar '11

On Sunday 20 March 2011 22:29:34 Joshua Beck wrote: > I erred on the side of caution because I didn't want to spend all summer > working on a project that I couldn't finish. Finding the right amount of work is certainly tricky. Luckily d3dx9 has many functions, so if you find out that you have plenty of time left you can include extra work in your project later on. You don't have to get the set of work perfect at the start - reevaluating the amount of work needed and adjusting the goals during the project is part of gsoc. However, finding a most likely doable, but not overly simple set of work does improve the application. We'll provide feedback on this(as I just did, I hope others who know the library better will jump in if I am telling you incorrect things) > However I do have other > ideas that I would also like to implement. For instance, I would be > willing to implement the D3DXSave[Surface/Texture]ToFile* functions for > all file formats currently supported by WINE. Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad)

2 2

Re: [GSoC] Merge winecfg and Control Panel
by wine.dev＠web.de 27 Mar '11

27 Mar '11

Dear Tony Welcome to Wine. > > After all the searches, I still do not have an overall idea of how to > create an control panel applet. From my current understanding, if I put the > cpl (dll) file in "~/.wine/drive_c/windows/system32/", wine control will > recognize it automatically, right? When you add a new cpl, the wine build system does this for you. > If so, is there any instructions on how to build a simple applet under wine > (even one that does nothing could work for me). I'd really like to try > create and build some test applet in order to understand it better. As always: Read the source. What you try to do (test applet) is how i started with inetcpl.cpl a while ago. git has a web interface with a history and the first commit for inetcpl.cpl is a minimalistic control applet. ( http://source.winehq.org/git/wine.git/history/HEAD:/dlls/inetcpl.cpl ) -- by by ... Detlef

3 2

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported
by Stefan Dösinger 26 Mar '11

26 Mar '11

> <0001-wined3d-check-for-ARB_fragment_program-in-arbfp_blit.patch> Considering this statement in select_blit_implementation, directx.c: if ((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) && gl_info->supported[ARB_FRAGMENT_PROGRAM]) return &arbfp_blit; else return &ffp_blit; How does wined3d end up using arbfp_blit?

2 2