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

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Henri Verbeet

On 31 May 2011 12:50, Alexandre Julliard <julliard(a)winehq.org> wrote: > I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but > by defining it when necessary, i.e. if neither d3d8types.h nor > d3d9types.h have been included already. > > This way d3d8 uses the d3d8 definition, d3d9 uses the d3d9 definition, > and ddraw/d3d10/wined3d internals use the wined3d definition which is > probably a superset of the others. > It's called WINED3DPOOL instead of D3DPOOL since it's a wined3d type, but otherwise I think that's close enough to what we currently have that it's practically the same. Conceptually I think it makes sense to have a distinction between wined3d types and e.g. ddraw types. For things like D3DPOOL that's not strictly required since it has the same values in all d3d versions where it exists, but e.g. format IDs are incompatible between versions. In that sense calling it WINED3DPOOL instead of D3DPOOL is mostly just a matter of consistency. On the other hand, perhaps the more fundamental point is that I'm not so sure that "superset of all d3d versions" is the correct level of abstraction for wined3d. I suspect we'll see that break down a bit as we implement more of d3d10/11, and perhaps also with some ddraw cleanups. (To pick a random example, consider d3d10/11 sampler states vs d3d8/9 sampler states.) Note that WINED3DPOOL is a terrible example though, since it should go away in favor of d3d10 style CPU/GPU access masks in the medium to long term anyway. Similarly, it makes much more sense to fix something like IDirect3DTexture8Impl_GetType() by replacing most of the function with just "return D3DRTYPE_TEXTURE;" instead of introducing the d3dresourcetype_from_wined3dresourcetype() function. The existing code should be perfectly valid C, though perhaps not all that pretty in some places. Clang throws some warnings, but well, tough. It's not very high on my list of things I want to spend time thinking about. At this point we probably spent more time talking about it than fixing those enum conversion warnings would ever save anyone. Except for the cases that are obvious to fix / improve, I think it's probably best to just leave it alone. Maybe it will go away if we ignore it.

June 4, 2011

Re: cmd: ensure create_full_path returns FALSE for all errors

by Dan Kegel

2011/6/4 Dan Kegel <dank(a)kegel.com>: > https://testbot.winehq.org/JobDetails.pl?Key=11484 > It passes on all tested platforms. Feel free to > submit along with your patch verbatim if it looks > sufficient to you. BTW it looks like cmd test suite completely ignores stderr, which explains why that test passes even though the error message produced by wine's cmd and native cmd are different.

June 4, 2011

Re: cmd: ensure create_full_path returns FALSE for all errors

by Dan Kegel

2011/6/4 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > On Sat, Jun 4, 2011 at 19:27, Dan Kegel <dank(a)kegel.com> wrote: >> Please add a test case, too. > > OK. Do I need a testbot account as well? Yeah. The cmd test suite is touchy, so it's worth it to use testbot to verify your test before you send it to wine-patches. I threw an example test case together for you. A quick run on xp seems to indicate you also need to set errorlevel, so I added that. See the patch attached to https://testbot.winehq.org/JobDetails.pl?Key=11484 It passes on all tested platforms. Feel free to submit along with your patch verbatim if it looks sufficient to you. (Oddly, windows xp's cmd doesn't seem to set errorlevel if you use rmdir on a nonexistent directory...) - Dan

June 4, 2011

gdi speed: 10x slower than real win

by Jarek Czekalski

Hi Devels The app I use runs unacceptably slow under wine. I suspected gdi routines and wrote a simple win32 api app to make some tests and comparisons. On my box it shows wine gdi is 10 times slower than the real windows. Let's get into details. REASON I love EditPad Pro (appdb editpad pro <http://appdb.winehq.org/objectManager.php?sClass=application&iId=8392>), a text editor with the capabilities for a programmer that I can't find in any other tool. After upgrade from version 6 to 7 I have problems with the usability, due to slow performance. The app is written in Delphi and now they included new interface features. The menus seem to be animated, they roll down instead of popping up immediately. Menus roll down slowly on wine, but that's a little problem, just a noticable thing. I have problems with very typing characters and these problems are almost gone when I switch off all the toolbars. Looks like the icons on them make them slow down the whole app. The author of the app claims that on his vmwared ubuntu everything is ok. I hope to get the judgement from you. TESTING APP I attach zip with source code and the executable of a short win32 api. It's an animated rectangle, optionally with a bitmap inside. It moves pixel by pixel from left to right. The next move is generated by PostMessage(WM_USER) at the end of OnPaint. I hope that's a way of assessing the gdi speed. Time needed to make the full pass of 500 pixels is printed on the screen. RESULTS test_gdi.exe without parameters draws bitmapped rect, while with the option "t" - the rect is bare. I tested 3 evironments and took 2 measurings on each of them. First number is the bitmapped time. Units are seconds. wine 0.39 0.22 - every movement phase is drawn vmwared w2k 0.123 0.085 - only several painted rects in random places w2k 0.0387 0.0285 - several painted every 2nd line, skewed rects The factor of 10 comes from comparing bitmapped time between wine and real W2K. Wine graphics is perfect, and the faster environments take some shorter ways. POSSIBLE EXPLANATION Just my imagination. I guess Windows buffer their graphics outcome in memory. Fast changes in this memory are not passed to the graphic device. This would explain the artifacts seen in the experiment and also the lack of flickering of the apps under the real win. For example mentioned EditPadPro redraws its edit area with every character typed (at least in the syntax highlighting mode), while under real win this behaviour is undetectable. BIBLIOGRAPHY The speed issue was reviewed in such posts I could locate: GDI Question <http://www.winehq.org/pipermail/wine-devel/2003-February/014052.html> (2003) Windows 2D GDI benchmark tools? <http://www.winehq.org/pipermail/wine-devel/2009-July/077144.html> (2009) Speed problem with Wine... <http://www.winehq.org/pipermail/wine-users/2001-July/007320.html> (2001) Has anything changed? LAST WORD I hope you'll benefit from the tester I wrote. I'm looking forward to see your comments. Do you notice the same speed multiplier as me: 10x? Maybe I have to fix my Debian to reach better results. Jarek

June 4, 2011

Re: dinput: Added a check for NULL callback in EnumDevices.

by Lucas Zawacki

> Sometimes apps depend on the crash. Since your change comes with a > test case, it looks reasonable to me, although you might check the > specific HRESULT rather than just FAILED. Exactly, it's not a crash on Windows. I'll resend it with an explicit test. I was thinking of this more as "janitorial" work as opposed to fixing a buggy app, maybe my comment worded it badly.

June 4, 2011

Re: cmd: ensure create_full_path returns FALSE for all errors

by Frédéric Delanoy

On Sat, Jun 4, 2011 at 19:27, Dan Kegel <dank(a)kegel.com> wrote: > Please add a test case, too. OK. Do I need a testbot account as well?

June 4, 2011

Re: dinput: Added a check for NULL callback in EnumDevices.

by Juan Lang

> I don't. I just thought that a case where Wine misbehaving causes a > crash was worth fixing. Sometimes apps depend on the crash. Since your change comes with a test case, it looks reasonable to me, although you might check the specific HRESULT rather than just FAILED. --Juan

June 4, 2011

Re: dinput: Added a check for NULL callback in EnumDevices.

by Lucas Zawacki

> Do you have an example of such application? And the bug in bugzilla? > I don't. I just thought that a case where Wine misbehaving causes a crash was worth fixing.

June 4, 2011

re: cmd: ensure create_full_path returns FALSE for all errors

by Dan Kegel

Please add a test case, too.

June 4, 2011

Re: wined3d: Enable blit stretching for 64 bpp

by Roderick Colenbrander

Hi André, I'm not sure if we should add this change since for a part it hides the real problem. Sure this patch likely works, but >32bpp blits should never enter the software rendering code in the first place. The code used to be a huge mess and Henri cleaned it up quite a bit already (thanks, because I became too busy). It may be easier now to fix this properly. Roderick 2011/6/4 André Hentschel <nerv(a)dawncrow.de>: > For http://bugs.winehq.org/show_bug.cgi?id=27377 > --- > dlls/wined3d/surface.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 91b16a6..7f9d9df 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -6780,6 +6780,9 @@ do { \ > case 4: > STRETCH_ROW(DWORD); > break; > + case 8: > + STRETCH_ROW(DWORD64); > + break; > case 3: > { > const BYTE *s; > -- > > Best Regards, André Hentschel > > >

June 4, 2011