September 2011 - Wine-Devel

Re: Using ApiTrace to improve D3D/OpenGL performance

by Emanuele Oriani

I guess if you can reproduce the same exact frames, then probably you can get real FPS your videocard might crunch, duplicated operation and maybe improve/exclude paths of code which slow down the 'real' rendering? Cheers On 30/09/11 21:15, Henri Verbeet wrote: > On 30 September 2011 22:07, Emanuele Oriani<emaentra(a)ngi.it> wrote: >> This might be useful to understand where some bottlenecks of wined3d might >> be? >> What do you think? >> > Yeah, I'm aware of apitrace, through Mesa. I haven't used it for > debugging wined3d so far, but I probably will at some point. I'm not > sure it's really suited for profiling wined3d much though, other than > for creating something reproducible to profile. (That's useful, but > doesn't solve the entire problem.) >

Sept. 30, 2011

Re: Using ApiTrace to improve D3D/OpenGL performance

by Henri Verbeet

On 30 September 2011 22:07, Emanuele Oriani <emaentra(a)ngi.it> wrote: > This might be useful to understand where some bottlenecks of wined3d might > be? > What do you think? > Yeah, I'm aware of apitrace, through Mesa. I haven't used it for debugging wined3d so far, but I probably will at some point. I'm not sure it's really suited for profiling wined3d much though, other than for creating something reproducible to profile. (That's useful, but doesn't solve the entire problem.)

Sept. 30, 2011

Using ApiTrace to improve D3D/OpenGL performance

by Emanuele Oriani

Dear all, Just wanted to bring to your attention ApiTrace 2.0, http://zrusin.blogspot.com/2011/09/apitrace-20.html . Apparently this tool is quite fast and should allow to play back GL commands, to analyse performance and replay commands. This might be useful to understand where some bottlenecks of wined3d might be? What do you think? Cheers

Sept. 30, 2011

design comments in code or in tests?

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

Hi, here's another one you WineConf folks may want to discuss. I've already expressed that there are not enough comments in mmdevapi's code. I thought about adding some, but wondered whether there's any value in using the header format that old code in Wine uses/used for automated doc. Generation (whatever the exact format was). For instance, comments ought to document GetPosition's contract in sufficient detail: - 0 <= GetPosition <= sum of written samples (modulo Frequency) - underruns don't count, it's no wall clock - monotically increasing(?) - should reflect speaker position, not buffering (MSDN says that) Don't look up MSDN. If that were complete enough, I would not have had the need to write as many tests as I did. Then I thought about placing comments in dlls/*/tests/ instead, because the test code is thrown away less often than the dll code. Seriously. Regards, Jörg Höhle

Sept. 30, 2011

Subject: [PATCH 1/2 (try2)] mmdevapi: Don't fail if dwChannelMask is not set correctly

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

Hi, Andrew Eikum writes: >(try2): Remove the test found by testbot. My Win7 Home VM passed that >test, so it seems we can expect any behavior. I object to the removal of the test like that. It should be replaced with a comment to explain that the behaviour of IsFormatSupported is very surprising, hence skipped. Actually, that behaviour begs for even more tests to understand what's going on. So far I believed in the invariant: IsFormatSupported == S_OK <=> Initialize == S_OK which is verified using all standard formats (1-2 channels), with one exception on testbot: render.c:396: Initialize (1, 48000x16x1) returns 8889000f unlike IsFormatSupported ^1^ means in exclusive mode, and only there. Now you experienced A. on testbot: IsFormatSupported(dwChannelMask==FFFF) == S_OK, like Initialize which conforms to the above invariant and simply suggests that ChannelMask is not checked at all, therefore this code in Wine seems too much: + fmtex->dwChannelMask != 0 && + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) B. your own Win7 Home system, with dwChannelMask=ffff, IsFormatSupported returns + ok(hr == S_FALSE || hr == AUDCLNT_E_UNSUPPORTED_FORMAT while Initialize returns + ok(hr == S_OK, which is weird. When does IFS return UNSUPPORTED_FORMAT? When does it return S_FALSE? In the latter case, is the suggested format anything else than GetMixFormat? What does exclusive mode return? Unlike in Wine, the shared mode "audio engine" mixer is a completely different SW entity than the exclusive mode "audio device", so it's important to check both. This needs more testing. In particular, tests performed on HW that supports more than 2 channels are welcome. Based on your surprising test result, I'd guess yours is such a system. Unlike DSound, mmdevapi has no GetSpeakerConfig that I'm aware of (short of Device Topology), so I don't know how apps find out about multi-channel abilities. BTW, I believe + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) in Wine is bogus anyway, because it's arbitrary. There exist different 3/4/5/6 channel configurations. Regards, Jörg Höhle

Sept. 30, 2011

Re: winscard

by Mounir IDRASSI

On 9/30/2011 4:47 PM, Marcus Meissner wrote: >> + State = pStates[i].dwEventState& (~SCARD_STATE_CHANGED); >> > + rgReaderStates[i].cbAtr = pStates[i].cbAtr; >> > + memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); > The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr > which seems to be the bytecount? I'll answer this since these patches are taken from my original big patch: copying cbAtr bytes makes more sens but copying MAX_ATR_SIZE is not wrong since the two buffers are of the same size and here we are just transferring all bytes from pcsclite side to the WIN32 side. That being said, maybe putting pStates[i].cbAtr will help the patches be accepted. By the way, I want to thank Vincent for taking the time to try to incorporate the winscard code into Wine. Without his dedication, this could languish for many years more! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr

Sept. 30, 2011

Re: user32: Prioritize focus for dialog owner on EndDialog.

by Erich Hoover

On Fri, Sep 30, 2011 at 8:36 AM, Marvin <testbot(a)testbot.winehq.org> wrote: > ... > === W7PROX64 (64 bit msg) === > Timeout > > === TEST64_W7SP1 (64 bit msg) === > Timeout It seems that these 64-bit tests have been failing for a while (it's clearly not related to my patch). Is anyone already looking into this issue? If not then I'll take a crack at it. Erich Hoover ehoover(a)mines.edu

Sept. 30, 2011

Re: winscard

by Marcus Meissner

On Fri, Sep 30, 2011 at 11:42:26AM +0200, Vincent Hardy wrote: > Hi all, > > Here are four patches that are a partial but functional > implementation of winscard. > > I installed "Belgian Electronic Identity Card MiddleWare" > (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) > > I tested winscard by starting beid35gui.exe and I can see my > identity card data. > > Moreover, this should help to solve this bug > http://bugs.winehq.org/show_bug.cgi?id=26978. > > Are these 4 patches good enough to be sent to wine-patch ? Patch looks largely good to me. 1 comment I have on quick review below. It is probably hard to write testcases that work without hardware, but if you can think of any, they would be welcome. .... > + State = pStates[i].dwEventState & (~SCARD_STATE_CHANGED); > + rgReaderStates[i].cbAtr = pStates[i].cbAtr; > + memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? With that clarified you could already send them to wine-patches as-is. Ciao, Marcus

Sept. 30, 2011

Re: user32: Prioritize focus for dialog owner on EndDialog.

by Marvin

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=14644 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout === TEST64_W7SP1 (64 bit msg) === Timeout

Sept. 30, 2011

Re: winscard

by Jeff Latimer

On 30/09/11 19:42, Vincent Hardy wrote: > > Are these 4 patches good enough to be sent to wine-patch ? Vincent, normally you would start by adding tests that can confirm the same behaviour in Windows. If you can do that and get the test accepted then you are a long closer to get your patches accepted too. As you start with the tests you need to code the tests for functions you have not implemented in the same patch as a todo wine so that the test will not break the wine test suite.

Sept. 30, 2011