April 2011 - Wine-Devel - list.winehq.org

Re: comctl32/tests: Remove practically unused parameters from test functions

by Nikolay Sivov

On 4/27/2011 17:53, Vitaliy Margolen wrote: > On 04/27/2011 01:14 AM, Nikolay Sivov wrote: >> Remove practically unused parameters from test functions >> > > So how is global variable any better then local variable passed as > function parameter? Because there's no need to have different parent windows for currently present tests. I don't see a reason of having window handle created exactly once and then passed in each test function, it's tests after all with a straightforward structure. > > IMHO this is s wrong thing to do - to move everything as global > variables just to move it back whenever need arises. I don't see when it's needed to pass different parent window. Even more, you'll need to create another parent before test function call. I prefer to have START_TEST(..){} as short as possible without any additional logic. Ideally we shouldn't use the same parent for different test calls at all to make them completely separate and not affecting each other. > > Vitaliy.

April 27, 2011

winealsa.drv: Add mmdevapi driver.

by Joerg-Cyril.Hoehle＠t-systems.com

Andrew Eikum wrote: >>Does CoTaskMemFree match HeapAlloc? >would anyone more familiar with CoTaskMem* want to comment? [cbSize slot present?] >Hm, to my surprise it seems MS no longer does this check as of Win7. Well, it's consistent with the documentation. So it's only the winmm API that has to be careful. >I went with the easy and probably good enough solution of >only supporting a few common rates. I may make perfectly sense with the new API. Modern apps seem to use mostly 48000 these days, with a few 22050 to mix for fun. >We'll just have to be careful in >WinMM to pass a valid structure through. Not only that. Old winmm apps expect weird rates like 9128 to work. So winmm->mmdevapi may not be a simple pass-through. OTOH, winmm probably won't use isFormatSupported and just get what ALSA returns. Hmm... We should add one winmm test with such a weird rate and expect all Wine machines to play it. An idea that goes a long way is to use a powerful machine to run software from a less powerful one. Here powerful translates to "pretend to be equipped with one of the best quality and least troublesome sound cards that the old SW might have known". The argument is not unlike http://source.winehq.org/source/dlls/wined3d/directx.c#L2048 /* Default to generic Nvidia hardware based on the supported OpenGL extensions. The choice * for Nvidia was because the hardware and drivers they make are of good quality. This makes * them a good generic choice. */ That's probably a card which could play weird rates and several samples concurrently. Thus if my poor on-board audio card can't, the middleware (Wine or ALSA) ought to do it, resampling and mixing as needed, given that the powerful machine is fast enough to do that. That's IMHO why dmix is the ALSA backend that Wine should expect: an allrounder. Wine should not try to deal itself with the idiosyncrasies of current audio cards. Well, that's my opinion. YMMV, especially if you want to use Wine to run the most recently released apps, then you probably expect Wine to deal with weird (but modern) audio HW and drivers -- like MS has done for 2 decades. Regards, Jörg Höhle

April 27, 2011

Re: comctl32/tests: Remove practically unused parameters from test functions

by Vitaliy Margolen

On 04/27/2011 01:14 AM, Nikolay Sivov wrote: > Remove practically unused parameters from test functions > So how is global variable any better then local variable passed as function parameter? IMHO this is s wrong thing to do - to move everything as global variables just to move it back whenever need arises. Vitaliy.

April 27, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Stefan Dösinger

On Wednesday 27 April 2011 01:16:27 Henri Verbeet wrote: > This is mostly the same as the previous version. I'll add my 2 cents and one crappy patch to this discussion. It is fairly similar to Adam's patch, but attempts to avoid redundant FBO work at a higher level. The patch is pretty quick and dirty, a few things need improvement: *) Integrate clears better. We can avoid redundant application in the clears itself, and reapplication after clearing the currently bound render target *) Marking the FBO dirty in context_bind_fbo is ugly. This should be done by the caller(s), mainly the blitting functions. I'm also not sure about context_apply_fbo_state_blit *) There are probably more places where the FBO has to be marked dirty, especially various surface operations *) There are some rendering bugs. Specifically, the flashlight in HL2 flickers when multicore rendering is enabled. This may be unrelated to the patch, but I don't think it is caused by the occlusion query problem. The patch has some debug code that prints out the number of FBO applications and the number of draws where nothing was done. In my testing the FBO is dirty between 2% and 10% of all draws, depending on the game. This is higher than expected, but I don't know yet if that's because apps change the render targets that often or because of clears. Anyway, Some performance results: game old new cubetest 101.06 114.21 TF2 78.79 79.21 hl2 145.24 146.87 nfs:shift main menu 16.83 17.07 tmnations 48.0 48.8 cubetest is my own draw overhead tester. For comparison, Windows 7 runs this app at 730 fps. It doesn't use offscreen rendering. The other apps use offscreen to some extent, in tmnations the FBO is dirty 2% of the time, in HL2 and TF2 around 8%. NFS:Shift does a lot of blitting in the main menu and at the moment falls back to software blitting, so this result is fairly uninteresting.

April 27, 2011

Question on Conformance Test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, James McKenzie wrote: >I realize that WindowsNT 4.0 is our base configuration IMHO that doesn't matter. Winecfg's default changed from w95 to w2k to xp while I was looking. >What would be the BEST method of annotating this: >ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); >or: >ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); You judge: - If you feel both results are quite logical, use ||. - I've used broken() to document which values Wine shall *not* return. That's IMHO an underestimated use of broken(). - OTOH, I've used || specifically when I thought Wine might/should perhaps change behavior in the future, such that no future patch would be needed to turn GetLastError() == WINXP_ERROR || broken(GetLastError() == WINNT40_ERROR) into broken(GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR - ... which never prevented me from writing todo_wine ok(broken(NT.../*what Wine returns today*/) || XP /*what I want it to return*/, ... (rather than that, put broken last). Regards, Jörg Höhle

April 27, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Tue, Apr 26, 2011 at 10:30 PM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Tue, Apr 26, 2011 at 4:15 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> > wrote: >> >> > Completely unimplemented: >> > - ConvertPointRepsToAdjacency >> > - ConvertAdjacencyToPointReps >> > - UpdateSemantics >> >> Ok so I can still work on ConvertPointRepsToAdjacency and >> ConvertAdjacencyToPointReps? >> > Yes. I had no plans on working on them. > Nor do I plan on fully implementing CloneMesh, so I'll try to submit what I > have in order to let you can build on it. Great I'll work on those first and then plan to improve CloneMesh later in the summer.

April 27, 2011

Question on Conformance Test

by James McKenzie

All: I am writing a conformance test for the richedit function EM_FINDWORDBREAK. I realize that WindowsNT 4.0 is our base configuration and most of the values process the same. However, a couple of values process differently for Windows NT 4.0/Windows2000, WindowsXP/Windows2003 and Windows Vista onward. What would be the BEST method of annotating this: Per the development guide: ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); or: ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); In other words, should I avoid the use of Broken() in this case, as the returned value is correct? Thank you. James McKenzie

April 27, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Stefan Dösinger

On Wednesday 27 April 2011 01:19:51 Stefan Dösinger wrote: > On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as > > WINED3DZB_TRUE.\n", > > > stateblock->state.render_states[WINED3DRS_ZENABLE]); > > > > + /* falltrough */ > > > + case WINED3DZB_TRUE: > Please provide a test for this. Actually that should have been a reply to "wined3d/state: Treat unrecognized D3DZBUFFERTYPEs as WINED3DZB_TRUE." I guess I should have gone to sleep a while ago...

April 26, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Stefan Dösinger

On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as WINED3DZB_TRUE.\n", > stateblock->state.render_states[WINED3DRS_ZENABLE]); > + /* falltrough */ > + case WINED3DZB_TRUE: Please provide a test for this.

April 26, 2011

Re: wined3d/query: Add support for timestamp queries.

by Stefan Dösinger

I think timestamp queries are supposed to return GPU-side timestamps. Otherwise I don't see the point in adding a complex d3d query around QueryPerformanceFrequency. There's GL_ARB_timer_query which looks like it does what you need.

April 26, 2011